From owner-freebsd-virtualization@freebsd.org Wed Apr 4 15:25:27 2018 Return-Path: Delivered-To: freebsd-virtualization@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 ACFB5F96F33 for ; Wed, 4 Apr 2018 15:25:27 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mx0.gentlemail.de (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 34AE6813EE for ; Wed, 4 Apr 2018 15:25:26 +0000 (UTC) (envelope-from freebsd@omnilan.de) Received: from mh0.gentlemail.de (ezra.dcm1.omnilan.net [IPv6:2a00:e10:2800::a135]) by mx0.gentlemail.de (8.14.5/8.14.5) with ESMTP id w34FPIid079530; Wed, 4 Apr 2018 17:25:18 +0200 (CEST) (envelope-from freebsd@omnilan.de) Received: from titan.inop.mo1.omnilan.net (s1.omnilan.de [217.91.127.234]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mh0.gentlemail.de (Postfix) with ESMTPSA id 2A098804; Wed, 4 Apr 2018 17:25:18 +0200 (CEST) Message-ID: <5AC4EE5C.9030906@omnilan.de> Date: Wed, 04 Apr 2018 17:25:16 +0200 From: Harry Schmalzbauer Organization: OmniLAN User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; de-DE; rv:1.9.2.8) Gecko/20100906 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Daniel Braniss CC: "Rodney W. Grimes" , freebsd-virtualization@freebsd.org Subject: Re: bhyve and arp problem References: <201804021611.w32GB9G4083257@pdx.rh.CN85.dnsmgr.net> <5AC25809.30205@omnilan.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (mx0.gentlemail.de [IPv6:2a00:e10:2800::a130]); Wed, 04 Apr 2018 17:25:18 +0200 (CEST) X-Milter: Spamilter (Reciever: mx0.gentlemail.de; Sender-ip: ; Sender-helo: mh0.gentlemail.de; ) X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Apr 2018 15:25:27 -0000 Bezüglich Daniel Braniss's Nachricht vom 04.04.2018 15:08 (localtime): > > >> On 2 Apr 2018, at 19:19, Harry Schmalzbauer wrote: >> >> Bezüglich Rodney W. Grimes's Nachricht vom 02.04.2018 18:11 (localtime): >>>> Bez?glich Daniel Braniss's Nachricht vom 02.04.2018 16:58 (localtime): >>>> >>>> ? >>>>>> >>>>>> Are you trying to use the HOSTS ip address in the GUEST? >>>>> >>>>> the client is using the server?s /usr/local, which is mounted via nfs. >>>> >>>> I guess you have reasons to prefer nfs over nullfs. >>> >>> You can not nullfs mount from inside a bhyve guest the host file >>> system would be his reason. >> >> Doh, of course – I mind-mixed with jails… Almost all my FreeBSD >> "guests" on a bhyve(8) host are jails... Please simply ignore ;-) >> >> >> … >>>> your results... Else I can't explain what you see other than the above >>>> scenario. >>> >>> Is it still true that if you have a bridge hooked to an interface >>> you must move the IP assignement from the interace device to the >>> bridge? >> >> I have no idea, I haven't used if_bridge(4) for some years. Perferably >> I use vale(4) (if I don't need .11q) or ng_bridge(4) for bhyve(8) setups. >> >> -harry > > maybe this could be the cause: > on the server, every time a client is started iI see: > kernel: bridge0: error setting interface capabilities on mlxen0 Members added to the bridge will automatically get some (TX) offloadings disabled, which seems to fail in your case. man 4 if_bridge: The TOE, TSO, TXCSUM and TXCSUM6 capabilities on all interfaces added to the bridge are disabled if any of the interfaces doesn't support/enable them. The LRO capability is always disabled. All the capabilities are restored when the interface is removed from bridge. Changing capabilities in run time may cause NIC reinit and the link flap. I don't think the kernel-bridge0-logs are related to your ARP issue – txcsum offloading enabled on if_bridge(4) uplinks cause other errors (dropped packets – one layer up). -harry