From owner-freebsd-current@freebsd.org Sat Feb 10 07:53:05 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 175BBF04D3D; Sat, 10 Feb 2018 07:53:05 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7E8B271833; Sat, 10 Feb 2018 07:53:04 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from thor.intern.walstatt.dynvpn.de ([77.179.129.41]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0La3c1-1f7cmA1LDx-00lpQC; Sat, 10 Feb 2018 08:52:55 +0100 Date: Sat, 10 Feb 2018 08:52:21 +0100 From: "O. Hartmann" To: "Bjoern A. Zeeb" Cc: "O. Hartmann" , freebsd-jail@freebsd.org, freebsd-current Subject: Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing Message-ID: <20180210085248.7b9af104@thor.intern.walstatt.dynvpn.de> In-Reply-To: <2D57FE3A-744A-4A44-B572-5338AB9E187D@lists.zabbadoz.net> References: <20180208093052.7f5d7a98@freyja.zeit4.iv.bundesimmobilien.de> <20180209172259.1ec9b9f4@thor.intern.walstatt.dynvpn.de> <2D57FE3A-744A-4A44-B572-5338AB9E187D@lists.zabbadoz.net> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; boundary="Sig_/iZ3C2Do29sYhN8rpa4JmBL/"; protocol="application/pgp-signature" X-Provags-ID: V03:K0:vEgHj1sxHwePDeyJjnZM50fzClp8+HZzt122w1gU1aNx8FJy2Pz FecjtkqUzU5MS/RnuMJzXrcjbzSLj09mbcHPTk9ZgRVM8L5kaq5aqXq1+aqSXp5y2F8/MYh yK/xpUC1MgZfu7dE9244gjvxbTABW2iz6gl+5bgb99GBXLiuHkTov4oSqas43GRkQxJYzxM EC9Qt/Ss08/3kY/h9g0Jg== X-UI-Out-Filterresults: notjunk:1;V01:K0:MY4N0F7pXmk=:ufCY0ULHzRRMTXgrKOi+i8 sXAYSdia46wkS3hLw9yvhVGea/oQTpx+opja5VwuUbURsKFXHoTYUvhxeYOczZAz/QHjFmga/ 4kiJkMvF0QXRik6pf+cZS1NvvXHmj3QPupoWVDRp31bBTRbCusze9DzfKutoHBomsQNc71UGa xxIt72DVoamCPCXbKoFSbSZd/OCDgQPFgvA9wGRiTMujLpk3t5oJVsRbBgZj/g5mLdzVYTRUj gB3LM2WIm4ryiI1RBbgvhVBii+17T2tVgf4Vu3FUgh8da48kS0RmpKCDC9yyyEe8QaxeknY+E +Zf2BvW3VO7mFSI6TIfASKMVtLohxVHVXh5f6Q/KXjjX6XfXE65spV3TDaJxeHOq8U0Pe614U VP8njaYf4LjLdaHZVFL8fKaPcW/FsDCv2j0ZyupO50+R1Z9C9L1aIRpTm7HuFwSVH0wiCzOsc 3F/5I+Fxm/Tsq6R3r9dZH8UVnLP1pU2ykFe9U0Lu8h9KRBFp63xQU9BEcgZkpnEVgao1ydNuI jrOI/OyzhaPW7rbpErSPxQO5x5erBq0iTYnrEcMOqATLRuwiBFCk6Y3RQLAup/0gHOQpXydwn NXNBJZAFe7WhXej6aI05KIW57TMvknktx0J5oIWbTiOIXIxfNxHi2nmROrmwyPUspGwlV1P3F 9HdgPZqyMaw8GI+VvKOUJXc0wzZkO2F6SJOHYcjIz/x2jP6uhwC7b2Smyn6HqC/KGAGDo0cwq sR/ZrMCdAUI+MmsThECUDoLFKUyzbhw7zHhr2RCUKY/f9rgQHJ/rW+LzReOXsivntmIgPb5g0 Rxfem9Ykn6bIQBUtIDYYt29TyZZ5w== X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2018 07:53:05 -0000 --Sig_/iZ3C2Do29sYhN8rpa4JmBL/ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Am Fri, 09 Feb 2018 16:43:17 +0000 "Bjoern A. Zeeb" schrieb: > On 9 Feb 2018, at 16:22, O. Hartmann wrote: >=20 > > Am Thu, 8 Feb 2018 09:31:15 +0100 > > "O. Hartmann" schrieb: > > > > Is this problem to trivial? =20 >=20 > I read through it yesterday and found myself in the position that I need= =20 > a whiteboard or paper and pencil or an ASCII art of your situation. But= =20 > by the time I made it to the question I was basically lost. Could you=20 > massively simplify this and maybe produce the ASCII art? >=20 > /bz > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" All right. I'm not much of an artist and at this very moment, I haven't much experienc= e with neat ASCII art tools. But I'll provide a sketch later, but I also will simplify = the situation. Consider three "vswitches", basically based on the creation of bridges, bri= dge0, bridge1, bridge2. Create at least three individual vnet-jails attached to each vbrid= ge. Those jails have epair pseudo devices. The jail itself owns the "a-part" of the e= pair and the b-part is "member of the bridge". Each jail's epairXXXa has an IP assigned = of the network the vswitch is part of. I mention a- and b-part of the epair here, because = I thought it could matter, but I think for symmetry reasons it doesn't. Now consider a further, special jail. This jail is supposed to have three e= pair devices, each one is reaching into one of the vbridges. This jail is the router/rout= ing jail. Later, this jail should filter via IPFW the traffic between the three vbrid= ges according to rules, but this doesn't matter here, beacuase the basics are not working= as expected. Now the problems. It doesn't matter on which jail of the three vswitches I = login, the moment a vbridge has more than two member epairs (one is alway member of t= he routing jail, now consider a database jail and a webserver jail), pinging each jail= or the routing jail fails. It works sometimes for a couple of ICMP packets and the= n stops. If each vbridge has only one member jail, I have NO PROBLEMS traversing acc= ordingly to the static routing rules from one vbridge to any other, say from vbridge1 t= o vbridge0 or vbridge2 and any permutation of that. The moment any of the bridges gets an additional member epair interface (so= the bridge has at least three members including the on reaching into the virtual route= r jail) the vbridge seems to operate unpredictable (to me). Pinging jails memeber of th= at vbridge are unreachable. Technical information: The kernel has options IPFIREWALL, VIMAGE. The host's ipfw (kernel) decline= s packets by default. Each jail is configured to have ipfw "open". Thanks for the patience. Kind regards, O. Hartmann --Sig_/iZ3C2Do29sYhN8rpa4JmBL/ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWn6k0AAKCRDS528fyFhY lNE+AgCbqIMTxE2O3ejPWmxVBxfd3Kh5NSZ+NPpHkuJ7Gh/U6yuZLbJWsbgpccGR degqacPcwWakbJAnqdQ9uXurJXSnAf9e76H89cTGqs9KCrWTKrUWUrH5fKFcLhO/ dN47cv6ZUn7xKCcqeudC2NKQA1C18DG+W6DqD22LL50xLIGHzDlm =ZIqA -----END PGP SIGNATURE----- --Sig_/iZ3C2Do29sYhN8rpa4JmBL/--