From owner-freebsd-current@freebsd.org Tue Feb 13 08:04:11 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 A93B4F078B6; Tue, 13 Feb 2018 08:04:11 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 15F3B69FA7; Tue, 13 Feb 2018 08:04:10 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from freyja.zeit4.iv.bundesimmobilien.de ([87.138.105.249]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MdEsh-1f2thG0D8V-00IQLk; Tue, 13 Feb 2018 09:04:05 +0100 Date: Tue, 13 Feb 2018 09:03:58 +0100 From: "O. Hartmann" To: Marko Zec Cc: "O. Hartmann" , "Bjoern A. Zeeb" , , freebsd-current Subject: Re: VIMAGE: vnet, epair and lots of jails on bridgeX - routing Message-ID: <20180213090358.3729045e@freyja.zeit4.iv.bundesimmobilien.de> In-Reply-To: <20180210095449.3117e6d9@x23> References: <20180208093052.7f5d7a98@freyja.zeit4.iv.bundesimmobilien.de> <20180209172259.1ec9b9f4@thor.intern.walstatt.dynvpn.de> <2D57FE3A-744A-4A44-B572-5338AB9E187D@lists.zabbadoz.net> <20180210085248.7b9af104@thor.intern.walstatt.dynvpn.de> <20180210095449.3117e6d9@x23> Organization: Walstatt MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:IsPhPT5Ge3OatU0uG11pn72RAKohf+PH+WTfKT42c/RQcw+iKkF GtkBa+cTfyzaOcCYn1wFrx81So9noKlwXmlDNTRqRGwFAUoWeqQwq5MS3Dz/B8yiriLpWiH QZ/vPcHhlsUMt1z2MSH9VyrmSLMSLdrJ/v7llmpjUgebAg9pt+pxHxaWpGwSFUNWGTiCOqv Z8EzzS7GV5P7Y5DbnvcrQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:UAuk+mpzsuk=:+3YKZZIw9EsdYfRqlU74ex 1iUZUifTxHQFfsd2okdgFssuWlGcd18rNP9fksc1WmS3j3pr4dEEQE1rPtUG6ealfMZAZMb/g 5uQggT3d32AHX3pGaGMNG6mbiaHm18wppyTGg72lpMsYc5FlpBeZNlwhqWJQ3Ur0sYOrh1waO JM7VMRaW/6fR5ry44lPEypNArABvzORPg/U2RelYStouQjggwHxcGx214kfLUtBCbqzWDNaTf I6PO3cP6ZF72x6voqZLxRCFq2Ba03lCCCHv3lTaS3bMHTb1dxRfiuuJFda6jXIJOyV7I7x0rB oaKXwakCvctAFZ2AA6YdYibnlWuG2Y0lF1+tT25Hfxa0275KFgI/1vB6ONkcCH7h2oNfbZdbJ 0bqAzEHcZ5IBrw5FfzoQLEPaHhH3hI+fvcI0IlVHBWgfag4FNumRhH9Jp1xeTqFA8U61B6LZL KKXLPH3+Cbo/DdQ9pBMqqY0NOAaCDmkn14TMxFAEnY+qLLnpg7AOpY+iv5ASuPOv7PLrtQimK S3yhfjOXyUgjH6cyhxSCne8FE+7FrEAS6DijhWsxAhMEB2GXP+HUXunPitgD9irLMOzO8CtcS A3gx0LKmB+u5JoXshYGivCEoxFG5sUwpcTnssogmn7jytZMN6MoFJANweXhTBPkhVsz9Qrnm4 vPeFdz13QUTJhNKWD4KVqUFjmIjlHYjJ4wxotnBztI3QmYb+R/VLKRXkQ7NFEt754PMU9oHdr 4xpPmbXR7CtXlTZLm7/KL9jK3X00DnFymJPzxce3SnNKuhTq9aEajvDuKlqmAV6QPU+QO7nnK oRhqjeaOtQRZ2H1aTOjFDh9/xFCxnaIpK34DrPO43Aol8ZJ0GE= 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: Tue, 13 Feb 2018 08:04:12 -0000 On Sat, 10 Feb 2018 09:54:49 +0100 Marko Zec wrote: > On Sat, 10 Feb 2018 08:52:21 +0100 > "O. Hartmann" wrote: > > > Am Fri, 09 Feb 2018 16:43:17 +0000 > > "Bjoern A. Zeeb" schrieb: > > > > > On 9 Feb 2018, at 16:22, O. Hartmann wrote: > > > > > > > Am Thu, 8 Feb 2018 09:31:15 +0100 > > > > "O. Hartmann" schrieb: > > > > > > > > Is this problem to trivial? > > > > > > I read through it yesterday and found myself in the position that I > > > need a whiteboard or paper and pencil or an ASCII art of your > > > situation. But by the time I made it to the question I was > > > basically lost. Could you massively simplify this and maybe > > > produce the ASCII art? > > > > > > /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 > > experience 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, bridge0, bridge1, bridge2. Create at least three individual > > vnet-jails attached to each vbridge. Those jails have epair pseudo > > devices. The jail itself owns the "a-part" of the epair 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 epair devices, each one is reaching into one of the vbridges. > > This jail is the router/routing jail. Later, this jail should filter > > via IPFW the traffic between the three vbridges 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 the 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 then > > stops. > > > > If each vbridge has only one member jail, I have NO PROBLEMS > > traversing accordingly to the static routing rules from one vbridge > > to any other, say from vbridge1 to 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 router jail) the vbridge seems to operate > > unpredictable (to me). Pinging jails memeber of that vbridge are > > unreachable. > > > > Technical information: > > > > The kernel has options IPFIREWALL, VIMAGE. The host's ipfw (kernel) > > declines packets by default. Each jail is configured to have ipfw > > "open". > > > > Thanks for the patience. > > If you could provide a script which sets up the topology you described > in two lengthy posts then others could reproduce this, and your chances > of getting useful feedback would certainly increase. > > We also have a graphical tool (https://github.com/imunes/imunes) which > can set up a topology like you described in a few clicks of a mouse, > albeit using netgraph and ng_eiface instead of epairs, but I assume this > is irellevant as long as you are not aiming for maximum packet > throughputs. If you attempt to use this tool, note that selecting > "stpswitch" will create if_bridge instances, whereas "lanswitch" > creates ng_bridge instances. > > Good luck, > > Marko > > > > > > Kind regards, > > > > O. Hartmann > > _______________________________________________ > 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" Hello Marko, thanks for your response. First of all: I looked at "imunes". From the first glimpse it looks great! Something really usefull; I regret not having a port for this tool or the chance to package it via poudriere. The problems I faced seem to be related to a bug Olivier Cochard-Labbe pointed me at: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176671 Checking the MAC of the epairs created revealed, that either doubles or even more occur on the host side of the epair (in my case, all the b-parts of an epair), or, if there is nothing irregular, then the a-parts (owned by the VIMAGE jail) have same MAC. The more jails I create, the more ambiguous MACs are present. It is the first time I ran into a more complex network topology and thanks for the hint using netgraph. Kind regards, Oliver