Hi, Alex--
On Aug 31, 2018, at 3:49 PM, Alex wrote:
> The interface does show some packet loss:
>
> br0: flags=4163 mtu 1500
> [ ... ]
>RX packets 1610535 bytes 963148307 (918.5 MiB)
>RX errors 0 dropped 5066 overruns 0 frame 0
>
> Is some packet loss such as the above to
Hi,
On Fri, Aug 31, 2018 at 5:54 PM Darcy, Kevin wrote:
>
> I'll second the use of tcpdump, and also add that DNS query traffic, using
> UDP by default, tends to be hypersensitive to packet loss. TCP will retry and
> folks may not even notice a slight drop in performance, but DNS queries,
>
I'll second the use of tcpdump, and also add that DNS query traffic, using
UDP by default, tends to be hypersensitive to packet loss. TCP will retry
and folks may not even notice a slight drop in performance, but DNS
queries, under the same conditions, can fail completely. Thus, DNS is often
the
tcpdump is your newest best friend to troubleshoot network issues. You need to
see what (if anything) is being placed on the wire and the responses (if any).
My goto syntax is:
tcpdump -n -i eth0 port domain
I like -n because it prevents a PTR lookup from happing. Why add extra noise?
As
Hi,
Would someone please help me understand why I'm receiving so many
timeouts? This is on a fedora28 system with bind-9.11.4 acting as a
mail server and running on a cable modem.
It appears to happen during all times, including when the link is
otherwise idle.
31-Aug-2018 16:52:57.297
5 matches
Mail list logo
