Holger
I’m currently running a ZyXEL C1100Z VDSL2 modem.
At this point the hardware WAN interface (RE1) is configured with an MTU of
1500
In addition the PPPOE interface is configured with an MTU of 1492
Please see below for more info:
[patrick@Firewall etc]$sysctl -a | grep ifq
net.inet.ip.ifq.len=0
net.inet.ip.ifq.maxlen=256
net.inet.ip.ifq.drops=0
net.inet6.ip6.ifq.len=0
net.inet6.ip6.ifq.maxlen=256
net.inet6.ip6.ifq.drops=0
net.mpls.ifq.len=0
net.mpls.ifq.maxlen=256
net.mpls.ifq.drops=0
################################
Please note the router was rebooted to test previously mentioned PF changes
excluding the conservative optimization which appears to be needed.
[patrick@Firewall etc]$sudo pfctl -si
Password:
Status: Enabled for 0 days 11:04:33 Debug: err
State Table Total Rate
current entries 82
searches 11655637 292.3/s
inserts 19621 0.5/s
removals 19539 0.5/s
Counters
match 22179 0.6/s
bad-offset 0 0.0/s
fragment 0 0.0/s
short 0 0.0/s
normalize 0 0.0/s
memory 0 0.0/s
bad-timestamp 0 0.0/s
congestion 0 0.0/s
ip-option 0 0.0/s
proto-cksum 0 0.0/s
state-mismatch 10 0.0/s
state-insert 0 0.0/s
state-limit 0 0.0/s
src-limit 0 0.0/s
synproxy 0 0.0/s
translate 12 0.0/s
Regards
Patrick
> On Dec 19, 2016, at 3:40 AM, Holger Glaess <gla...@glaessixs.de> wrote:
>
> hi
>
> what kind of DSL you have ( DSL or VDSL2 ) ?
>
> if you use VDSL2 is AUTO MTU Active ? ( Mother Interface
> have to be set to MTU 1508 , and no MTU Setting das the PPPOE
> Interface.)
>
> what says pfctl -si ( Line congestion )
>
> what say sysctl -a | grep ifq ?
>
> holger
>
>
>
>
>> Stuart
>>
>> Thanks for the reply
>>
>> At this point it appears a specific LAN client âPS4â is
responsible
>> for a
>> high number of device interrupts.
>>
>> Hoping to clarify if interrupts In excess of â3000â can cause
PPPOE
>> timeouts.
>>
>>
#############################################################################
>> #
>> Lan Streaming cat5 no switch
>>
>> procs memory page disk traps cpu
>> r b w avm fre flt re pi po fr sr sd0 int sys cs us
>> sy
>> id
>> 1 0 0 18636 3825560 1 0 0 0 0 0 0 6872 7 10 0 9 91
>> 0 0 0 18636 3825560 1 0 0 0 0 0 0 2163 7 9 0 4 96
>> 0 0 0 18636 3825560 1 0 0 0 0 0 0 1921 9 11 0 2 98
>> 0 0 0 18636 3825560 1 0 0 0 0 0 0 1943 6 9 0 3 97
>> 0 0 0 18636 3825560 1 0 0 0 0 0 0 1705 6 9 0 3 97
>> 0 0 0 18636 3825560 1 0 0 0 0 0 0 1849 8 10 0 3 97
>> 0 0 0 18636 3825560 1 0 0 0 0 0 0 2276 6 9 0 4 96
>>
>>
############################################################################
>> Wlan Streaming
>>
>> procs memory page disk traps cpu
>> r b w avm fre flt re pi po fr sr sd0 int sys cs us
>> sy
>> id
>> 1 0 0 18632 3825732 1 0 0 0 0 0 0 368 7 10 0 1 99
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 365 8 10 0 2 98
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 355 10 9 0 1 99
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 362 9 10 0 2 98
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 356 8 10 0 1 99
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 361 10 10 0 1 99
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 365 9 10 0 2 98
>> 0 0 0 18632 3825732 1 0 0 0 0 0 0 383 8 10 0 1 99
>>
>>
#############################################################################
>> No Lan or Wlan traffic
>>
>> procs memory page disk traps cpu
>> r b w avm fre flt re pi po fr sr sd0 int sys cs
>> us sy
>> id
>> 1 0 0 18628 3825736 1 0 0 0 0 0 0 24 8 10 0 0
>> 100
>> 0 0 0 18628 3825736 1 0 0 0 0 0 0 23 6 9 0 0
>> 100
>> 0 0 0 18628 3825736 1 0 0 0 0 0 0 28 6 9 0 0
>> 100
>> 0 0 0 18628 3825736 1 0 0 0 0 0 0 24 8 10 0 0
>> 100
>> 0 0 0 18628 3825736 1 0 0 0 0 0 0 22 7 9 0 0
>> 100
>> 0 0 0 18628 3825736 1 0 0 0 0 0 0 25 8 10 0 0
>> 100
>> 0 0 0 18628 3825736 1 0 0 0 0 0 0 24 6 9 0 0
>> 100
>>
>> Regards
>> Patrick
>>
>>> On Dec 15, 2016, at 5:05 AM, Stuart Henderson <s...@spacehopper.org>
>>> wrote:
>>>
>>> On 2016-12-15, Patrick Dohman <patrick_doh...@centurylink.net> wrote:
>>>> Stuart
>>>>
>>>> Please see below for more info:
>>>>
>>>> Please note the 5.7 dmesg is subsequent to a reboot.
>>>
>>> Thanks. I was wondering about a bug with LCP echoes I accidentally
>>> introduced that made it into 5.9 (fixed for 6.0).
>>>
>>> Nothing stands out from what you've sent. Some possibilities:
>>>
>>> - connection somewhere between the APU and the ISP really is dropping
>>> out
>>> (are you using the same cable for the different locations you placed the
>> APU
>>> in? could a cable be bad? check for errors on the ethernet interface)
>>>
>>> - machine too busy to handle traffic - maybe tail -f /var/log/messages
>>> in
>> the
>>> background while "vmstat -w 10" or something is running (maybe under
>> "script"),
>>> look for the timeouts in the output and see what cpu is doing at the
>>> time
>>>
>>>> pass out quick on egress inet6 proto { tcp, udp } from {
>>>> (pppoe0:network),
>>>> (athn0:network), (re2:network) } modulate state
>>>
>>> btw using (...) causes an extra address lookup to be done when the rule
>>> is evaluated (i.e. when a packet doesn't match existing state) - you may
>> need
>>> this for pppoe0 but you can save a bit of cpu with
>>>
>>> pass out quick on egress inet6 proto { tcp, udp } from {
>>> (pppoe0:network),
>>> athn0:network, re2:network } modulate state
>>>
>>> (and same for the v4 rule)
>>>
>>>> ### --- Optional Runtime Options --- ###
>>>> set optimization conservative
>>>
>>> not likely to be the problem, but you're pretty unlikely to need that.
