Date: Thu, 10 Mar 2022 14:00:25 +0000 (UTC) From: "Bjoern A. Zeeb" <bz@freebsd.org> To: Wolfgang Zenker <zenker@punkt.de> Cc: Kristof Provost <kp@freebsd.org>, Johan Hendriks <joh.hendriks@gmail.com>, mops@punkt.de, FreeBSD Net <freebsd-net@freebsd.org> Subject: Re: epair and vnet jail loose connection. Message-ID: <alpine.BSF.2.00.2203101351580.68830@ai.fobar.qr> In-Reply-To: <Yinw91TbJjOFdQNn@punkt.de> References: <051d51b6-2a07-fbc6-7b4d-13947e7fcdbb@gmail.com> <CF7D877C-E6AC-4FB3-92D8-68E54580631F@punkt.de> <65a18f1b-ea22-a3d2-b4ad-41fd52b7fbae@gmail.com> <CC8129F5-A596-43EA-9F26-834DD4DC60F0@FreeBSD.org> <Yinw91TbJjOFdQNn@punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-287681838-1646920525=:68830 Content-Type: TEXT/PLAIN; CHARSET=UTF-8; FORMAT=flowed Content-Transfer-Encoding: 8BIT Content-ID: <alpine.BSF.2.00.2203101355411.68830@ai.fobar.qr> On Thu, 10 Mar 2022, Wolfgang Zenker wrote: Hi, >>> I did do a hey -h2 -n 10 -c 10 -z 60s https://wp.test.nl to that machine and in the 60 seconds the jail became unresponsive. Then i did run the dtrace.sh script above like so /root/bin/dtrace.sh > /root/dtrace_output >>> >>> I hope this helps, if you need anything please let me know. Also root access is possible if you want. That way you do not have to create a test environment. > >> Were there other epair interfaces running at this time, with active traffic? > >> The dtrace output appears to show that the appropriate callouts (to epair_tx_start_deferred()) are getting through, so I’d expect traffic to be flowing. > > There is one second jail using epair on that system, using the same > bridge as well. This second jail is a low-traffic system, it is unlikely > but possible that there was some traffic during that time. Were you bridging or routing? I seem to remember if_bridge being loaded from loader? So you'll always have some broad-/multi-cast. > In all previous cases this second jail continued to be reachable all > the time. I don't know the latest incarnations of epair code very well anymore. I'd probably go and look at stats (netstat etc) for the interface and possibly protocols as well before restarting the jail; check if there are packets queued, dropped exacessively or if the in/out packet coutners are still increasing (on both sides)? I'd probably also run a tcpdump then on both sides of the epair to see if packets are still arriving on one side and not the other? And if it is a bridging setup, I wonder if taking that out of the picture (you could remove the epair end from the bridge, put an address on it and send a ff02::1 mc ping6 or something) and see. Also does setting the epairs down/up (on both ends) make any differences? I am basically trying to narrow things down, as restarting entire jails and with that a network stack is a lot more changes than just epair. /bz -- Bjoern A. Zeeb r15:7 --0-287681838-1646920525=:68830--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.2203101351580.68830>