From owner-freebsd-jail@freebsd.org Thu Jul 25 19:24:35 2019 Return-Path: Delivered-To: freebsd-jail@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31A81AC7B8 for ; Thu, 25 Jul 2019 19:24:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 1239391960 for ; Thu, 25 Jul 2019 19:24:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 11CE5AC7B6; Thu, 25 Jul 2019 19:24:35 +0000 (UTC) Delivered-To: jail@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 119ACAC7B5 for ; Thu, 25 Jul 2019 19:24:35 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E6E879195E for ; Thu, 25 Jul 2019 19:24:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id C2CEC37F7 for ; Thu, 25 Jul 2019 19:24:34 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x6PJOYcc052892 for ; Thu, 25 Jul 2019 19:24:34 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x6PJOYcC052891 for jail@FreeBSD.org; Thu, 25 Jul 2019 19:24:34 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: jail@FreeBSD.org Subject: [Bug 239417] ARP ping fails from the host to bridged vnet jails Date: Thu, 25 Jul 2019 19:24:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 12.0-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: yuri@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: net@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-Rspamd-Queue-Id: E6E879195E X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.97 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.97)[-0.970,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2019 19:24:35 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D239417 --- Comment #5 from Yuri Victorovich --- (In reply to Eugene Grosbein from comment #4) Hi Eugene, I am doing this in the context of the containerization application that I am working on, yet unannounced (https://github.com/yurivict/crate). It is alre= ady functional, but needs networking and configuration management bits to be ad= ded or fixed. It runs programs and services in jails, and connects them to network dynamically using firewall rules or bridges. The main mode of connectivity is the "blend" mode when it blends with the h= ost IP address using epair(4) and firewall rules. This doesn't involve creation= of IP addresses, and I have it working, except for some minor details. The secondary mode is the "lan" mode which creates a dedicated LAN IP addre= ss for each container. I asked this question originally for this mode. Your suggestion about moving the IP address to the bridge makes sense. The proce= ss looks a bit more invasive than I originally thought it would be, because it would involve altering the network settings, moving the IP to another inter= face for the life of container or all containers and then moving it back, as per your advise. I will try this. This is only needed to find a spare LAN IP to allocate, and is not needed for subsequent container operation. Also this "= lan" mode isn't strictly necessary because the "blend" mode should satisfy most = use cases. I just came up with it, and thought that it would be interesting to implement it too. Thank you for your help! Yuri --=20 You are receiving this mail because: You are on the CC list for the bug.=