Hi Alex,
On Mon, 1 Oct 2018 12:51:46 -0400
Alex wrote:
> I believe I said as many as 500 qps, but I believe that's wrong. It's
> more like a sustained 200 q/s.
One other thing you might double check is whether or not any consumer
equipment (cable modem, router) has a firewall setting that
Hi,
On Mon, Oct 1, 2018 at 9:58 AM Blake Hudson wrote:
>
> Alex wrote on 9/30/2018 7:27 PM:
> > Hi,
> >
> > On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote:
> >> On 30 Sep 2018, at 09:59, Alex wrote:
> >>> It also tends to happen in bulk - there may be 25 SERVFAILs within the
> >>> same second,
Hi,
> > It also tends to happen in bulk - there may be 25 SERVFAILs within
> > the same second, then nothing for another few minutes.
>
> Hmmm. If it isn't the modem and it isn't the BLs then it more or less
> has to be the service, no?
Yes, most likely, but I was looking for more definitive
On 9/30/18, Alex wrote:
> Hi,
>
> On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote:
>>
>> On 30 Sep 2018, at 09:59, Alex wrote:
>> > It also tends to happen in bulk - there may be 25 SERVFAILs within the
>> > same second, then nothing for another few minutes.
>>
>> That really makes it seem like
Alex wrote on 9/30/2018 7:27 PM:
Hi,
On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote:
On 30 Sep 2018, at 09:59, Alex wrote:
It also tends to happen in bulk - there may be 25 SERVFAILs within the
same second, then nothing for another few minutes.
That really makes it seem like either you
Hello again,
On Mon, 1 Oct 2018, Alex wrote:
> Are your requests being dropped by the service(s)?
>
> (Or: are you inadvertently abusing the said service(s)?)
I don't believe so - often times a follow-up host query succeeds
without issue. It's also failing for invaluement and spamhaus, both
> -Original Message-
> From: bind-users On Behalf Of Alex
> I'm leaning towards that, too. The problem persists even when using
> the provider's DNS servers. I thought for sure I'd see some verifiable
> info from other people having problems with cable, such as from
> dslreports, etc,
Hi,
On Sun, Sep 30, 2018 at 1:19 PM @lbutlr wrote:
>
> On 30 Sep 2018, at 09:59, Alex wrote:
> > It also tends to happen in bulk - there may be 25 SERVFAILs within the
> > same second, then nothing for another few minutes.
>
> That really makes it seem like either you modem or you ISP is
On 30 Sep 2018, at 09:59, Alex wrote:
> It also tends to happen in bulk - there may be 25 SERVFAILs within the
> same second, then nothing for another few minutes.
That really makes it seem like either you modem or you ISP is interfering
somehow, or is simply not able to keep up.
--
'Who's
Hi,
> > Sep 29 14:33:54 mail03 postfix/dnsblog[3290]: warning:
> > dnsblog_query: lookup error for DNS query
> > 123.139.28.66.dnsbl.sorbs.net: Host or domain name not found. Name
> > service error for name=123.139.28.66.dnsbl.sorbs.net type=A: Host
> > not found, try again
> >
> > I'd really be
Hi there,
On Sun, 30 Sep 2018, Alex wrote:
Sep 29 14:33:54 mail03 postfix/dnsblog[3290]: warning:
dnsblog_query: lookup error for DNS query
123.139.28.66.dnsbl.sorbs.net: Host or domain name not found. Name
service error for name=123.139.28.66.dnsbl.sorbs.net type=A: Host
not found, try again
Hi,
> DOCSIS cable systems use an upstream request/grant system to avoid
> collisions (they act as a hub where only one cable modem in the node can
> transmit at the same time). This leads to low pps rates compared with
> ethernet. Even a 10M ethernet connection (1k-10k pps) will outperform a
>
Alex wrote on 9/26/2018 11:52 AM:
This is all now running on a 165/35 cable system.
Early in this thread or another, I provided a packet trace that showed
what appears to me to never have received the replies - it just times
out.
It looks like there are periods of as many as 500
On 9/28/18 9:26 AM, Alex wrote:
>> Has your provider enabled qos? I'd bet their dropping packets that
>> exceed qos rate limits would be considered "working as expected".
>
> I asked and they had no idea what that even meant. The technician that
> was here replacing the modem also had no idea
On 9/28/18, Alex wrote:
> Hi,
>
> On Fri, Sep 28, 2018 at 12:18 AM Lee wrote:
>>
>> 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
Hi,
On Fri, Sep 28, 2018 at 12:18 AM Lee wrote:
>
> 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
Hi,
> 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?
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
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
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of
> Alex
> Sent: Thursday, 27 September 2018 2:52 AM
> To: bind-users@lists.isc.org
> Subject: BIND and UDP tuning
>
> Hi,
>
> I reported a few weeks ago that I was experiencing a really high
>
30 matches
Mail list logo
