On 9/27/18, Alex wrote:
> Hi,
>
>> Just a wild thought:
>> It works with a lower speed line (at least I read it that way) but has
>> problems with higher speeds.
>> Could it be that the line is so fast that it "overtakes" the host in
>> question?
>>
>> A faster incoming line will give less time
Hi Alex,
Have you tried on a separate physical server? To rule out the actual
hardware as being the problem?
Is this some user grade PC with either onboard or external ethernet
interface, or a proper server grade equipment? Age of equipment? What
else does that machine do?
Cheers
On
Hi,
> Just a wild thought:
> It works with a lower speed line (at least I read it that way) but has
> problems with higher speeds.
> Could it be that the line is so fast that it "overtakes" the host in question?
>
> A faster incoming line will give less time between the packets for processing.
When we ran into UDP tuning issues on high traffic devices it presented as
silent discards rather than SERVFAIL.
On Thu, Sep 27, 2018, 12:04 PM Alex wrote:
> Hi,
>
> > On Thu, Sep 27, 2018 at 10:53:25AM -0400, Alex wrote:
> > > Many of these values I've already tweaked and have had no effect on
Hi,
> > This is also only happening on the two identical systems connected
> > to the 165/35mbit cable modem.
> > ...
> > I really hope there is > someone with some additional ideas.
>
> Is it the modem?
No, it's been replaced at least once, and I've been assured by both
the cable tech that was
Hi,
> On Thu, Sep 27, 2018 at 10:53:25AM -0400, Alex wrote:
> > Many of these values I've already tweaked and have had no effect on my
> > SERVFAIL issues :-(
>
> If you are getting SERVFAILs from a BIND resolver you administer, then
> it has responded to your query. If you turn up the log level
Hi there,
On Thu, 27 Sep 2018, Alex wrote
This is also only happening on the two identical systems connected
to the 165/35mbit cable modem.
...
I really hope there is > someone with some additional ideas.
Is it the modem?
--
73,
Ged.
___
Please
On Thu, Sep 27, 2018 at 10:53:25AM -0400, Alex wrote:
> Many of these values I've already tweaked and have had no effect on my
> SERVFAIL issues :-(
If you are getting SERVFAILs from a BIND resolver you administer, then
it has responded to your query. If you turn up the log level to
something
On 27/09/2018 16.53, Alex wrote:
> Hi,
>
>>> I reported a few weeks ago that I was experiencing a really high
>>> number of "SERVFAIL" messages in my bind-9.11.4-P1 system running on
>>> fedora28, and I haven't yet found a solution. This is all now running
>>> on a 165/35 cable system.
>>>
>>> I
Having multiple CNAME records for the same hsotname is a violation of
rfc1034. (that and bind9 won't allow it...)
Surely there must be some creative solution which doesn't a) violate the
DNS specs and b) doesn't suggest the use of deprecated software (bind8).
Regards,
Bob
Hi,
> > I reported a few weeks ago that I was experiencing a really high
> > number of "SERVFAIL" messages in my bind-9.11.4-P1 system running on
> > fedora28, and I haven't yet found a solution. This is all now running
> > on a 165/35 cable system.
> >
> > I found a program named dropwatch which
> -Original Message-
> From: Tony Finch [mailto:d...@dotat.at]
>
> > - { name: 'net.ipv4.tcp_sack', value: 0 }
>
> Why? SACK is super important for TCP performance over links that have any
> degree of lossiness, and I don't recall hearing of any caveats.
>
> Tony.
> --
>
Browne, Stuart via bind-users wrote:
> - { name: 'net.ipv4.tcp_sack', value: 0 }
Why? SACK is super important for TCP performance over links that have any
degree of lossiness, and I don't recall hearing of any caveats.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
a just distribution
13 matches
Mail list logo
