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
