[gentoo-user] {OT} ISP requires MTU below 1500?

[gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

A while back I was having networking issues.  I eventually tried
drastically lowering the MTU of all the systems onsite and the issues
disappeared.  I always thought the issue was due to the MTU on our
modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
increased the MTU of our systems up to 1492 and haven't had any
issues.  Do certain ISPs require you to change the MTU of your entire
network, or is this likely due to our AT&T modem/router itself?

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[wabe]

Grant <emailgrant@gmail.com> wrote:

> A while back I was having networking issues.  I eventually tried
> drastically lowering the MTU of all the systems onsite and the issues
> disappeared.  I always thought the issue was due to the MTU on our
> modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
> increased the MTU of our systems up to 1492 and haven't had any
> issues.  Do certain ISPs require you to change the MTU of your entire
> network, or is this likely due to our AT&T modem/router itself?

AFAIK the MTU is defined for every network interface separately. For an
ADSL connection it is common that a lower MTU is needed because of the 
PPPoE header information that is encapsulated in the ethernet frames.
But in that case it is sufficient to lower the MTU just for the WAN 
interface that is connected to the DSL modem. 
If you don't use protocol encapsulation in your LAN then there should
be IMHO no reason for lowering the MTU of your internal interfaces.

--
Regards
wabe

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>> A while back I was having networking issues.  I eventually tried
>> drastically lowering the MTU of all the systems onsite and the issues
>> disappeared.  I always thought the issue was due to the MTU on our
>> modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
>> increased the MTU of our systems up to 1492 and haven't had any
>> issues.  Do certain ISPs require you to change the MTU of your entire
>> network, or is this likely due to our AT&T modem/router itself?
>
> AFAIK the MTU is defined for every network interface separately. For an
> ADSL connection it is common that a lower MTU is needed because of the
> PPPoE header information that is encapsulated in the ethernet frames.
> But in that case it is sufficient to lower the MTU just for the WAN
> interface that is connected to the DSL modem.
> If you don't use protocol encapsulation in your LAN then there should
> be IMHO no reason for lowering the MTU of your internal interfaces.


So I should be OK with 1492 MTU on the modem/router and 1500 inside
that LAN?    That hasn't been my experience but I haven't tried in a
while.  Wouldn't that lead to fragmentation issues?  Admittedly, my
understanding of this is weak.

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[wabe]

Grant <emailgrant@gmail.com> wrote:

> >> A while back I was having networking issues.  I eventually tried
> >> drastically lowering the MTU of all the systems onsite and the
> >> issues disappeared.  I always thought the issue was due to the MTU
> >> on our modem/router.  Today I read that AT&T DSL requires a 1492
> >> MTU so I increased the MTU of our systems up to 1492 and haven't
> >> had any issues.  Do certain ISPs require you to change the MTU of
> >> your entire network, or is this likely due to our AT&T
> >> modem/router itself?  
> >
> > AFAIK the MTU is defined for every network interface separately.
> > For an ADSL connection it is common that a lower MTU is needed
> > because of the PPPoE header information that is encapsulated in the
> > ethernet frames. But in that case it is sufficient to lower the MTU
> > just for the WAN interface that is connected to the DSL modem.
> > If you don't use protocol encapsulation in your LAN then there
> > should be IMHO no reason for lowering the MTU of your internal
> > interfaces.  
> 
> 
> So I should be OK with 1492 MTU on the modem/router and 1500 inside
> that LAN?    That hasn't been my experience but I haven't tried in a
> while.  Wouldn't that lead to fragmentation issues?  Admittedly, my
> understanding of this is weak.

FWIR it is sufficient when all interfaces that are connected to a 
layer 2 network are using the same MTU for the respective layer 3 
protocols. So it should be ok when the MTU of the (logical) ppp 
interface is set to 1492 even when the MTU of the (physical) Ethernet 
interface is set to 1500. This is the case for my router that is 
connected to my DSL modem. I don't have any network problems and 
always maximum internet speed.

I'm not a network expert and don't understand all the details. Also 
my English is not good enough to explain it in a better way. 
But to be honest, I'm not sure that I could explain it better in my 
native language. ;-)

Probably there are other members on this ML that can give your more
useful information about this topic.

--
Regards
wabe

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Bill Kenworthy]

On 09/20/16 10:35, wabe wrote:
> Grant <emailgrant@gmail.com> wrote:
>
>>>> A while back I was having networking issues.  I eventually tried
>>>> drastically lowering the MTU of all the systems onsite and the
>>>> issues disappeared.  I always thought the issue was due to the MTU
>>>> on our modem/router.  Today I read that AT&T DSL requires a 1492
>>>> MTU so I increased the MTU of our systems up to 1492 and haven't
>>>> had any issues.  Do certain ISPs require you to change the MTU of
>>>> your entire network, or is this likely due to our AT&T
>>>> modem/router itself?  
>>> AFAIK the MTU is defined for every network interface separately.
>>> For an ADSL connection it is common that a lower MTU is needed
>>> because of the PPPoE header information that is encapsulated in the
>>> ethernet frames. But in that case it is sufficient to lower the MTU
>>> just for the WAN interface that is connected to the DSL modem.
>>> If you don't use protocol encapsulation in your LAN then there
>>> should be IMHO no reason for lowering the MTU of your internal
>>> interfaces.  
>>
>> So I should be OK with 1492 MTU on the modem/router and 1500 inside
>> that LAN?    That hasn't been my experience but I haven't tried in a
>> while.  Wouldn't that lead to fragmentation issues?  Admittedly, my
>> understanding of this is weak.
> FWIR it is sufficient when all interfaces that are connected to a 
> layer 2 network are using the same MTU for the respective layer 3 
> protocols. So it should be ok when the MTU of the (logical) ppp 
> interface is set to 1492 even when the MTU of the (physical) Ethernet 
> interface is set to 1500. This is the case for my router that is 
> connected to my DSL modem. I don't have any network problems and 
> always maximum internet speed.
>
> I'm not a network expert and don't understand all the details. Also 
> my English is not good enough to explain it in a better way. 
> But to be honest, I'm not sure that I could explain it better in my 
> native language. ;-)
>
> Probably there are other members on this ML that can give your more
> useful information about this topic.
>
> --
> Regards
> wabe
>
Rather than guess and take random values read on the net - measure it.

Google calculate mtu - netgear and others show ways to test upstream to
get the ideal size using ping

You are looking for the largest MTU value before fragmentation starts to
occur.

BillK

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[waltdnes]

On Tue, Sep 20, 2016 at 11:34:32AM +0800, Bill Kenworthy wrote
> 
> Rather than guess and take random values read on the net - measure it.
> 
> Google calculate mtu - netgear and others show ways to test upstream to
> get the ideal size using ping
> 
> You are looking for the largest MTU value before fragmentation starts to
> occur.

  See https://www.dslreports.com/faq/695 for detailed instructions on
getting the maximum MTU for your setup.

-- 
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>> Rather than guess and take random values read on the net - measure it.
>>
>> Google calculate mtu - netgear and others show ways to test upstream to
>> get the ideal size using ping
>>
>> You are looking for the largest MTU value before fragmentation starts to
>> occur.
>
>   See https://www.dslreports.com/faq/695 for detailed instructions on
> getting the maximum MTU for your setup.


I followed the instructions and got this at first:

# ping -s 1472 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1472(1500) bytes of data.
From dsldevice (192.168.1.254) icmp_seq=1 Frag needed and DF set (mtu = 1492)
1480 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
time=93.9 ms

After that it wouldn't tell me "Frag needed" no matter how high I set
the MTU for the ping command, but maybe the above indicates that my
max MTU is 1492?

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Todd Goodman]

* wabe <wabenbau@gmail.com> [160919 20:50]:
> Grant <emailgrant@gmail.com> wrote:
> 
> > A while back I was having networking issues.  I eventually tried
> > drastically lowering the MTU of all the systems onsite and the issues
> > disappeared.  I always thought the issue was due to the MTU on our
> > modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
> > increased the MTU of our systems up to 1492 and haven't had any
> > issues.  Do certain ISPs require you to change the MTU of your entire
> > network, or is this likely due to our AT&T modem/router itself?
> 
> AFAIK the MTU is defined for every network interface separately. For an
> ADSL connection it is common that a lower MTU is needed because of the 
> PPPoE header information that is encapsulated in the ethernet frames.
> But in that case it is sufficient to lower the MTU just for the WAN 
> interface that is connected to the DSL modem. 
> If you don't use protocol encapsulation in your LAN then there should
> be IMHO no reason for lowering the MTU of your internal interfaces.
> 
> --
> Regards
> wabe

MTU is per network interface but you really don't want to end up having
your router fragment every IP packet because systems on your subnet are
using a larger MTU.

Todd

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>> > A while back I was having networking issues.  I eventually tried
>> > drastically lowering the MTU of all the systems onsite and the issues
>> > disappeared.  I always thought the issue was due to the MTU on our
>> > modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
>> > increased the MTU of our systems up to 1492 and haven't had any
>> > issues.  Do certain ISPs require you to change the MTU of your entire
>> > network, or is this likely due to our AT&T modem/router itself?
>>
>> AFAIK the MTU is defined for every network interface separately. For an
>> ADSL connection it is common that a lower MTU is needed because of the
>> PPPoE header information that is encapsulated in the ethernet frames.
>> But in that case it is sufficient to lower the MTU just for the WAN
>> interface that is connected to the DSL modem.
>> If you don't use protocol encapsulation in your LAN then there should
>> be IMHO no reason for lowering the MTU of your internal interfaces.
>>
>> --
>> Regards
>> wabe
>
> MTU is per network interface but you really don't want to end up having
> your router fragment every IP packet because systems on your subnet are
> using a larger MTU.
>
> Todd


That makes sense.  So in my case, I'm thinking 1492 MTU on every
interface in the network.

So I'm sure I understand, should everyone with a DSL connection set an
MTU of 1492 (or potentially lower) on all of their network interfaces
to avoid packet fragmentation?

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Todd Goodman]

* Grant <emailgrant@gmail.com> [160920 08:53]:
> >> > A while back I was having networking issues.  I eventually tried
> >> > drastically lowering the MTU of all the systems onsite and the issues
> >> > disappeared.  I always thought the issue was due to the MTU on our
> >> > modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
> >> > increased the MTU of our systems up to 1492 and haven't had any
> >> > issues.  Do certain ISPs require you to change the MTU of your entire
> >> > network, or is this likely due to our AT&T modem/router itself?
> >>
> >> AFAIK the MTU is defined for every network interface separately. For an
> >> ADSL connection it is common that a lower MTU is needed because of the
> >> PPPoE header information that is encapsulated in the ethernet frames.
> >> But in that case it is sufficient to lower the MTU just for the WAN
> >> interface that is connected to the DSL modem.
> >> If you don't use protocol encapsulation in your LAN then there should
> >> be IMHO no reason for lowering the MTU of your internal interfaces.
> >>
> >> --
> >> Regards
> >> wabe
> >
> > MTU is per network interface but you really don't want to end up having
> > your router fragment every IP packet because systems on your subnet are
> > using a larger MTU.
> >
> > Todd
> 
> 
> That makes sense.  So in my case, I'm thinking 1492 MTU on every
> interface in the network.
> 
> So I'm sure I understand, should everyone with a DSL connection set an
> MTU of 1492 (or potentially lower) on all of their network interfaces
> to avoid packet fragmentation?
> 
> - Grant

I would probably set the MTU to 1492 on each interface myself.

But it really depends upon the traffic mix and how "smart" ("dumb") the
devices on the network are.

TCP is likely using Path MTU Discovery to determine the TCP Maximum
Segment Size so that TCP traffic doesn't encounter IP fragmentation
end-to-end.  PMTU used to use ICMP packets to determine the end-to-end
MTU, but RFC4281 (I think) uses a method to work around the dropping or
filtering of ICMP packets.

However, there's different quality of implementations as well as
differences in whether the network stack uses the PMTUD for UDP and
other datagram traffic or not as well.

Todd

DISCLAIMER: It's been a number of years since I've been involved in
implementing any IP networking so things may have moved on since then.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
>> MTU is per network interface but you really don't want to end up having
>> your router fragment every IP packet because systems on your subnet are
>> using a larger MTU.
>>
>> Todd
>
>That makes sense.  So in my case, I'm thinking 1492 MTU on every
>interface in the network.
>
>So I'm sure I understand, should everyone with a DSL connection set an
>MTU of 1492 (or potentially lower) on all of their network interfaces
>to avoid packet fragmentation?

That depends on your traffic flow. But, then again, 8 bytes out of
1500 means that you're "losing" just 0.533% of the maximum payload and
fragmenting can mean you have to send/recv 2 Frames for each 1500 Byte
packet you see locally.


I've just tested that (with the MTU set at 1492, so with the ping
overhead of 28 bytes, that leaves 1464 ping-payload without fragmenting)
("ping -M do" disallows, "-M dont" allows fragmenting).


$ ping -n -c 1 -M do -s 1465 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
From 192.168.178.11 icmp_seq=1 Frag needed and DF set (mtu = 1492)

--- www.dslreports.com ping statistics ---
0 packets transmitted, 0 received, +1 errors

==== corresponding tcpdump -n -i eth0 icmp ====
[nothing]
====


Ok, go down a byte:


$ ping -n -c 1 -M do -s 1464 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1464(1492) bytes of data.
1472 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=136 ms

--- www.dslreports.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 136.638/136.638/136.638/0.000 ms

==== corresponding tcpdump -n -i eth0 icmp ====
15:48:39.587143 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3656, seq 1, length 1472
15:48:39.723751 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3656, seq 1, length 1472
====


One packet sent and received for 1492 bytes packet size / 1464 bytes payload.


$ ping -n -c 1 -M dont -s 1465 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms

--- www.dslreports.com ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms

==== corresponding tcpdump -n -i eth0 icmp ====
15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, seq 1, length 1472
15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 1, length 1472
15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
====


Two packets sent and received for 1493 bytes packet size / 1465 bytes
ping-payload.

Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
yourself to see, that you'll send/recv 2 packets for each ping-packet
(and 1472 bytes is the ping-payload that just fits into the standard
1500 bytes MTU).

So, unless you have Gigs of internal traffic (and then you should have
a look at jumbo frames and might tune those to split nicely) and
little to the 'net, I'd definitely prefer losing those 8 bytes of
payload over sending double the packets (esp. with TCP, if just one of
those two of the fragmented bigger frame gets lost on the way, _both_
have to be retransmitted, as both TCP ends don't know (AFAIK, at least
usually?) about the fragmentation taking place inbetween, so basically
you're doubling the risk for lost TCP-packets for the "end-user" ...

With larger frames used internally (jumbo-frames) it gets complicated,
so I just send you to
https://en.wikipedia.org/wiki/IP_fragmentation
https://en.wikipedia.org/wiki/IPv4#Fragmentation_and_reassembly

And there's Path-MTU though. No idea if that works via the last-mile
PPPoE etc.

Disclaimer: I just know the basics of networking (and where to search
for what ;)

-dnh

-- 
I got an expresso maker at orkplace.  Expresso maker is deemed too complex by
all but me & PFY.  All expresso maker are belong to us.  :)  Caffeine is good.
Bzzzzzzzzz....                                          -- Mike Raeder

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>>> MTU is per network interface but you really don't want to end up having
>>> your router fragment every IP packet because systems on your subnet are
>>> using a larger MTU.
>>>
>>> Todd
>>
>>That makes sense.  So in my case, I'm thinking 1492 MTU on every
>>interface in the network.
>>
>>So I'm sure I understand, should everyone with a DSL connection set an
>>MTU of 1492 (or potentially lower) on all of their network interfaces
>>to avoid packet fragmentation?
>
> That depends on your traffic flow. But, then again, 8 bytes out of
> 1500 means that you're "losing" just 0.533% of the maximum payload and
> fragmenting can mean you have to send/recv 2 Frames for each 1500 Byte
> packet you see locally.
>
>
> I've just tested that (with the MTU set at 1492, so with the ping
> overhead of 28 bytes, that leaves 1464 ping-payload without fragmenting)
> ("ping -M do" disallows, "-M dont" allows fragmenting).
>
>
> $ ping -n -c 1 -M do -s 1465 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
> From 192.168.178.11 icmp_seq=1 Frag needed and DF set (mtu = 1492)
>
> --- www.dslreports.com ping statistics ---
> 0 packets transmitted, 0 received, +1 errors
>
> ==== corresponding tcpdump -n -i eth0 icmp ====
> [nothing]
> ====
>
>
> Ok, go down a byte:
>
>
> $ ping -n -c 1 -M do -s 1464 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1464(1492) bytes of data.
> 1472 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=136 ms
>
> --- www.dslreports.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 136.638/136.638/136.638/0.000 ms
>
> ==== corresponding tcpdump -n -i eth0 icmp ====
> 15:48:39.587143 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3656, seq 1, length 1472
> 15:48:39.723751 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3656, seq 1, length 1472
> ====
>
>
> One packet sent and received for 1492 bytes packet size / 1464 bytes payload.
>
>
> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com
> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms
>
> --- www.dslreports.com ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms
>
> ==== corresponding tcpdump -n -i eth0 icmp ====
> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, seq 1, length 1472
> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 1, length 1472
> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
> ====
>
>
> Two packets sent and received for 1493 bytes packet size / 1465 bytes
> ping-payload.
>
> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
> yourself to see, that you'll send/recv 2 packets for each ping-packet
> (and 1472 bytes is the ping-payload that just fits into the standard
> 1500 bytes MTU).


Strangely, I'm able to ping with that command even with a very high -s value:

$ ping -c 4 -M dont -s 9999 www.dslreports.com
PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
time=331 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
time=329 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
time=329 ms
10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
time=329 ms

--- www.dslreports.com ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
[..]
>> $ ping -n -c 1 -M dont -s 1465 www.dslreports.com
>> PING www.dslreports.com (64.91.255.98) 1465(1493) bytes of data.
>> 1473 bytes from 64.91.255.98: icmp_seq=1 ttl=51 time=137 ms
>>
>> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
>> rtt min/avg/max/mdev = 137.888/137.888/137.888/0.000 ms
>>
>> ==== corresponding tcpdump -n -i eth0 icmp ====
>> 15:47:07.983484 IP 192.168.178.11 > 64.91.255.98: ICMP echo request, id 3595, seq 1, length 1472
>> 15:47:07.983494 IP 192.168.178.11 > 64.91.255.98: icmp
>> 15:47:08.121308 IP 64.91.255.98 > 192.168.178.11: ICMP echo reply, id 3595, seq 1, length 1472
>> 15:47:08.121343 IP 64.91.255.98 > 192.168.178.11: icmp
>> ====
>>
>>
>> Two packets sent and received for 1493 bytes packet size / 1465 bytes
>> ping-payload.
>>
>> Try with e.g. 'ping -c 4 -M dont -s 1472 www.dslreports.com' for
>> yourself to see, that you'll send/recv 2 packets for each ping-packet
>> (and 1472 bytes is the ping-payload that just fits into the standard
>> 1500 bytes MTU).
>
>
>Strangely, I'm able to ping with that command even with a very high -s value:
>
>$ ping -c 4 -M dont -s 9999 www.dslreports.com
>PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>time=331 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>time=329 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>time=329 ms
>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>time=329 ms
>
>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms

Look again! You're just looking at the _PING_ packets, not the ICMP/IP
packets actually going over the interface! You'll need to run 
'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
there's two IP packets actually going over the interface, due to the
ping-packet being too large and being fragmented.

Start the tcpdump in another (x)term before running the "ping" ...

If you use '-M do', you should get the

    "Frag needed and DF set (mtu = NNNN)"

error from ping. "-M dont" explicitly allows fragmentation, which you
can then see with tcpdump. E.g. a with my MTU of 1492, a

==== ping -n -c 1 -M dont -s 9999 192.168.178.1 ====
PING 192.168.178.1 (192.168.178.1) 9999(10027) bytes of data.
10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms

--- 192.168.178.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms
====

results in

==== tcpdump -n -i eth0 icmp ====
17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 11363, seq 1, length 1472
17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp
17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, seq 1, length 1480
17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp
17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp
====

Yes, that is just the _one_ ping packet.

Read up on the links I gave you about fragmentation and IP(v4) in
general a bit ;) It's much better described there than I could ATM.

Which does not mean not to ask for stuff that's unclear.

HTH,
-dnh, who seems to have a knack for translating "techese" to normal
    language ... Actually, I guess fragmentation can be explained
    quite nicely by comparing to real-life packets ;) You'd get an
    basically unlimited supply of courier boys, but you can get just
    so many incoming and outgoing through the doors ;)

    *grepping out the appropriate sig for that*

-- 
No trees were destroyed in the sending of this message, however, a 
significant number of electrons were terribly inconvenienced.

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

>>Strangely, I'm able to ping with that command even with a very high -s value:
>>
>>$ ping -c 4 -M dont -s 9999 www.dslreports.com
>>PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>>time=331 ms
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>>time=329 ms
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>>time=329 ms
>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>>time=329 ms
>>
>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
>
> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
> packets actually going over the interface! You'll need to run
> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
> there's two IP packets actually going over the interface, due to the
> ping-packet being too large and being fragmented.
>
> Start the tcpdump in another (x)term before running the "ping" ...
>
> If you use '-M do', you should get the
>
>     "Frag needed and DF set (mtu = NNNN)"


I switched to '-M do' and found that 1464 is the highest size I can
ping without the "Frag needed" error.  This means I should add 28 to
that and set my MTU to 1492 across the network?

- Grant


> error from ping. "-M dont" explicitly allows fragmentation, which you
> can then see with tcpdump. E.g. a with my MTU of 1492, a
>
> ==== ping -n -c 1 -M dont -s 9999 192.168.178.1 ====
> PING 192.168.178.1 (192.168.178.1) 9999(10027) bytes of data.
> 10007 bytes from 192.168.178.1: icmp_seq=1 ttl=64 time=2.79 ms
>
> --- 192.168.178.1 ping statistics ---
> 1 packets transmitted, 1 received, 0% packet loss, time 0ms
> rtt min/avg/max/mdev = 2.795/2.795/2.795/0.000 ms
> ====
>
> results in
>
> ==== tcpdump -n -i eth0 icmp ====
> 17:40:11.901583 IP 192.168.178.11 > 192.168.178.1: ICMP echo request, id 11363, seq 1, length 1472
> 17:40:11.901597 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901599 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901600 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901602 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901603 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.901605 IP 192.168.178.11 > 192.168.178.1: icmp
> 17:40:11.903762 IP 192.168.178.1 > 192.168.178.11: ICMP echo reply, id 11363, seq 1, length 1480
> 17:40:11.903779 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.903984 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.903997 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904227 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904241 IP 192.168.178.1 > 192.168.178.11: icmp
> 17:40:11.904338 IP 192.168.178.1 > 192.168.178.11: icmp
> ====
>
> Yes, that is just the _one_ ping packet.
>
> Read up on the links I gave you about fragmentation and IP(v4) in
> general a bit ;) It's much better described there than I could ATM.
>
> Which does not mean not to ask for stuff that's unclear.
>
> HTH,
> -dnh, who seems to have a knack for translating "techese" to normal
>     language ... Actually, I guess fragmentation can be explained
>     quite nicely by comparing to real-life packets ;) You'd get an
>     basically unlimited supply of courier boys, but you can get just
>     so many incoming and outgoing through the doors ;)
>
>     *grepping out the appropriate sig for that*

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[David Haller]

Hello,

On Tue, 20 Sep 2016, Grant wrote:
>>>Strangely, I'm able to ping with that command even with a very high -s value:
>>>
>>>$ ping -c 4 -M dont -s 9999 www.dslreports.com
>>>PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
>>>time=331 ms
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
>>>time=329 ms
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
>>>time=329 ms
>>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
>>>time=329 ms
>>>
>>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
>>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
>>
>> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
>> packets actually going over the interface! You'll need to run
>> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
>> there's two IP packets actually going over the interface, due to the
>> ping-packet being too large and being fragmented.
>>
>> Start the tcpdump in another (x)term before running the "ping" ...
>>
>> If you use '-M do', you should get the
>>
>>     "Frag needed and DF set (mtu = NNNN)"
>
>
>I switched to '-M do' and found that 1464 is the highest size I can
>ping without the "Frag needed" error.  This means I should add 28 to
>that

The overhead of 28 bytes is just specific to ping.

It means that your upstream has a MTU of 1492 bytes. And it depends on
your local needs if setting this MTU network-wide is the best course. 
I think I and others wrote enough for you to decide.

>and set my MTU to 1492 across the network?

Probably yes. I'd even say: unless you know otherwise for your local
needs. It's a very small "pay" (-0.5% max throughput) locally for a
potentially much bigger gain towards the 'net side, esp. when
factoring in latency ... And BTW: changing the MTU is easy, why not
start with one system? Even temporarily just using ifconfig/ip
commandline (don't forget to set the default-route if you "down" the
connection: 'route add default gw $GW_IP' ) and running some
tests/benchmarks.

HTH,
-dnh

-- 
Actually, NT is more like LSD with all the good effects filtered out.
                                                     -- Andrew Maddox

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Mick]

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]

On Tuesday 20 Sep 2016 19:38:02 David Haller wrote:
> Hello,
> 
> On Tue, 20 Sep 2016, Grant wrote:
> >>>Strangely, I'm able to ping with that command even with a very high -s
> >>>value:
> >>>
> >>>$ ping -c 4 -M dont -s 9999 www.dslreports.com
> >>>PING www.dslreports.com (64.91.255.98) 9999(10027) bytes of data.
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=1 ttl=54
> >>>time=331 ms
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=2 ttl=54
> >>>time=329 ms
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=3 ttl=54
> >>>time=329 ms
> >>>10007 bytes from www.dslreports.com (64.91.255.98): icmp_seq=4 ttl=54
> >>>time=329 ms
> >>>
> >>>4 packets transmitted, 4 received, 0% packet loss, time 3003ms
> >>>rtt min/avg/max/mdev = 329.159/329.877/331.612/1.158 ms
> >>>
> >> Look again! You're just looking at the _PING_ packets, not the ICMP/IP
> >> packets actually going over the interface! You'll need to run
> >> 'tcpdump icmp' in parallel! "My ping" also just reports 1 packet, but
> >> there's two IP packets actually going over the interface, due to the
> >> ping-packet being too large and being fragmented.
> >> 
> >> Start the tcpdump in another (x)term before running the "ping" ...
> >> 
> >> If you use '-M do', you should get the
> >> 
> >>     "Frag needed and DF set (mtu = NNNN)"
> >
> >I switched to '-M do' and found that 1464 is the highest size I can
> >ping without the "Frag needed" error.  This means I should add 28 to
> >that
> 
> The overhead of 28 bytes is just specific to ping.
> 
> It means that your upstream has a MTU of 1492 bytes. And it depends on
> your local needs if setting this MTU network-wide is the best course.
> I think I and others wrote enough for you to decide.
> 
> >and set my MTU to 1492 across the network?
> 
> Probably yes. I'd even say: unless you know otherwise for your local
> needs. It's a very small "pay" (-0.5% max throughput) locally for a
> potentially much bigger gain towards the 'net side, esp. when
> factoring in latency ... And BTW: changing the MTU is easy, why not
> start with one system? Even temporarily just using ifconfig/ip
> commandline (don't forget to set the default-route if you "down" the
> connection: 'route add default gw $GW_IP' ) and running some
> tests/benchmarks.
> 
> HTH,
> -dnh

Leaving your MTU at the default ethernet size of 1500 on your PC/server should 
not cause a problem for most day to day operations, because modern end-point 
OS and network devices use Path MTU Detection.  Problems will arise when you 
come across a misconfigured router/firewall/server (internet black hole) which 
drops  ICMP Fragmentation Needed (Type 3, Code 4) packets and won't adjust its 
MTU to make sure you can receive packets of the appropriate size.

I have no idea if PMTUD is in any way relevant to the TCP queue spikes you 
have observed, but they are caused by TCP buffers overflowing.  Some detective 
work at the time these overflows take place would show what the server is doing 
at the time.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Grant]

> Leaving your MTU at the default ethernet size of 1500 on your PC/server should
> not cause a problem for most day to day operations, because modern end-point
> OS and network devices use Path MTU Detection.  Problems will arise when you
> come across a misconfigured router/firewall/server (internet black hole) which
> drops  ICMP Fragmentation Needed (Type 3, Code 4) packets and won't adjust its
> MTU to make sure you can receive packets of the appropriate size.


And I believe that's exactly what I have as far as my AT&T
modem/router which seems to drop all icmp packets.  I think that's why
it's important for me to set an MTU for my network which is not
greater than the MTU of the modem/router which appears to be 1492.


> I have no idea if PMTUD is in any way relevant to the TCP queue spikes you
> have observed, but they are caused by TCP buffers overflowing.  Some detective
> work at the time these overflows take place would show what the server is doing
> at the time.


Any idea which tool to use?  I could start keeping an eye on output
when things are good and then again when things are bad so I can
compare the two states.

- Grant

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Mick]

[-- Attachment #1: Type: text/plain, Size: 1637 bytes --]

On Tuesday 20 Sep 2016 12:57:00 Grant wrote:
> > Leaving your MTU at the default ethernet size of 1500 on your PC/server
> > should not cause a problem for most day to day operations, because modern
> > end-point OS and network devices use Path MTU Detection.  Problems will
> > arise when you come across a misconfigured router/firewall/server
> > (internet black hole) which drops  ICMP Fragmentation Needed (Type 3,
> > Code 4) packets and won't adjust its MTU to make sure you can receive
> > packets of the appropriate size.
> 
> And I believe that's exactly what I have as far as my AT&T
> modem/router which seems to drop all icmp packets.  I think that's why
> it's important for me to set an MTU for my network which is not
> greater than the MTU of the modem/router which appears to be 1492.
> 
> > I have no idea if PMTUD is in any way relevant to the TCP queue spikes you
> > have observed, but they are caused by TCP buffers overflowing.  Some
> > detective work at the time these overflows take place would show what the
> > server is doing at the time.
> 
> Any idea which tool to use?  I could start keeping an eye on output
> when things are good and then again when things are bad so I can
> compare the two states.
> 
> - Grant

On the server you could start by using iftop, iptraf-ng, netstat to get an 
idea of connections and bandwidth consumed.  Use lsof, syslog and webserver 
logs to see what's happening at an application level.

You can also increase the firewall verbosity briefly, to see if anything strange 
is happening with packets being processed there.
-- 
Regards,
Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

Re: [gentoo-user] {OT} ISP requires MTU below 1500?

[Alarig Le Lay]

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

On Tue Sep 20 07:52:58 2016, Todd Goodman wrote:
> MTU is per network interface but you really don't want to end up having
> your router fragment every IP packet because systems on your subnet are
> using a larger MTU.
> 
> Todd

You will not fragment every packet, the PMTUd will do his job and will
lower all the next packets.

-- 
alarig

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]

[gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Kai Krakow]

Am Mon, 19 Sep 2016 14:56:59 -0700
schrieb Grant <emailgrant@gmail.com>:

> A while back I was having networking issues.  I eventually tried
> drastically lowering the MTU of all the systems onsite and the issues
> disappeared.  I always thought the issue was due to the MTU on our
> modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
> increased the MTU of our systems up to 1492 and haven't had any
> issues.  Do certain ISPs require you to change the MTU of your entire
> network, or is this likely due to our AT&T modem/router itself?

Are you using tunnels or a firewall that blocks related "icmp
fragmentation needed" packets?

Please also try to find out if you're experiencing packet loss. If
fragmented packets cannot be reassembled due to some packets lost, you
will probably find connections freezing or going really slow.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Grant]

>> A while back I was having networking issues.  I eventually tried
>> drastically lowering the MTU of all the systems onsite and the issues
>> disappeared.  I always thought the issue was due to the MTU on our
>> modem/router.  Today I read that AT&T DSL requires a 1492 MTU so I
>> increased the MTU of our systems up to 1492 and haven't had any
>> issues.  Do certain ISPs require you to change the MTU of your entire
>> network, or is this likely due to our AT&T modem/router itself?
>
> Are you using tunnels or a firewall that blocks related "icmp
> fragmentation needed" packets?


I have this in shorewall/rules:

ACCEPT  all  all  icmp  -  -  -  10/sec:20

Which I believe accepts all icmp packets but throttles them to 10/sec
to avoid being flooded.  Is that OK?


> Please also try to find out if you're experiencing packet loss. If
> fragmented packets cannot be reassembled due to some packets lost, you
> will probably find connections freezing or going really slow.


I will watch the output of ifconfig today to see if there are any RX
or TX errors.

- Grant

[gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Kai Krakow]

Am Tue, 20 Sep 2016 05:42:01 -0700
schrieb Grant <emailgrant@gmail.com>:

> >> A while back I was having networking issues.  I eventually tried
> >> drastically lowering the MTU of all the systems onsite and the
> >> issues disappeared.  I always thought the issue was due to the MTU
> >> on our modem/router.  Today I read that AT&T DSL requires a 1492
> >> MTU so I increased the MTU of our systems up to 1492 and haven't
> >> had any issues.  Do certain ISPs require you to change the MTU of
> >> your entire network, or is this likely due to our AT&T
> >> modem/router itself?  
> >
> > Are you using tunnels or a firewall that blocks related "icmp
> > fragmentation needed" packets?  
> 
> 
> I have this in shorewall/rules:
> 
> ACCEPT  all  all  icmp  -  -  -  10/sec:20
> 
> Which I believe accepts all icmp packets but throttles them to 10/sec
> to avoid being flooded.  Is that OK?

You should probably add a rule before that to let pass all icmp traffic
related to active connections. I think this can be done with conntrack
or "-m related". I didn't use iptables in a long time so I cannot
exactly help you with instructions.

On the other hand, you're probably interested in only limiting icmp
echo-request. So you may want to stick with that and not limit icmp
altogether. ICMP is a very important part of a functional ip stack, you
should not play with it before fully understanding the consequences.

I don't think it makes too much sense to bother about icmp. In case,
icmp is dropped first usually - and limiting it on your interfaces
doesn't help at all against flooding (because your provider still
delivers it to your router through your downstream, it's too late to
do limiting at this stage), it just saves you from maybe replying to all
those packets (and thus saves upstream bandwidth which on standard
asymmetric lines is ridiculous small compared to the massive
downstreams).

But again: You really (!) should not limit icmp traffic with such a
general rule but instead limit only specific types of icmp (like
echo-request), and maybe even block other types completely on the
external interface (redirect, source quench, a few others).

Most others are important for announcing problems on the packet route -
like smaller MTU (path mtu discovery), unreachable destinations etc.
Unselectively blocking or limiting them will result in a lot of
timeouts and intermittent connection freezes which are hard to
understand.

http://www.nthelp.com/icmp.html

> > Please also try to find out if you're experiencing packet loss. If
> > fragmented packets cannot be reassembled due to some packets lost,
> > you will probably find connections freezing or going really slow.  
> 
> I will watch the output of ifconfig today to see if there are any RX
> or TX errors.

I almost expect you won't see any numbers there but instead see the
counter of your limit rule rise during periods where you see the
problems. TX and RX errors only catch layer 1 or layer 2 losses, you
are probably experiencing packet loss at or above layer 3 (and I guess
due to your limit rule).

Maybe run a ping to a destination which you are having problems with,
then reproduce the problem (with the network idle otherwise). You should
see ping packets dropped only then.

You can also ping with increasing packet sizes (see ping --help) and
see when the packet becomes too big for path MTU. But instead lowering
your MTU then, you should allow icmp-fragmentation-needed come through
reliably. Lowering MTU only makes sense to stop overly fragmentation in
the first place and optimize for a specific packet path (like traffic
through one or multiple VPN tunnels) where fragmentation would
otherwise increase latency a lot, or where icmp-frag-needed does not
correctly work.

-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Grant]

>> >> A while back I was having networking issues.  I eventually tried
>> >> drastically lowering the MTU of all the systems onsite and the
>> >> issues disappeared.  I always thought the issue was due to the MTU
>> >> on our modem/router.  Today I read that AT&T DSL requires a 1492
>> >> MTU so I increased the MTU of our systems up to 1492 and haven't
>> >> had any issues.  Do certain ISPs require you to change the MTU of
>> >> your entire network, or is this likely due to our AT&T
>> >> modem/router itself?
>> >
>> > Are you using tunnels or a firewall that blocks related "icmp
>> > fragmentation needed" packets?
>>
>>
>> I have this in shorewall/rules:
>>
>> ACCEPT  all  all  icmp  -  -  -  10/sec:20
>>
>> Which I believe accepts all icmp packets but throttles them to 10/sec
>> to avoid being flooded.  Is that OK?
>
> You should probably add a rule before that to let pass all icmp traffic
> related to active connections. I think this can be done with conntrack
> or "-m related". I didn't use iptables in a long time so I cannot
> exactly help you with instructions.
>
> On the other hand, you're probably interested in only limiting icmp
> echo-request. So you may want to stick with that and not limit icmp
> altogether. ICMP is a very important part of a functional ip stack, you
> should not play with it before fully understanding the consequences.
>
> I don't think it makes too much sense to bother about icmp. In case,
> icmp is dropped first usually - and limiting it on your interfaces
> doesn't help at all against flooding (because your provider still
> delivers it to your router through your downstream, it's too late to
> do limiting at this stage), it just saves you from maybe replying to all
> those packets (and thus saves upstream bandwidth which on standard
> asymmetric lines is ridiculous small compared to the massive
> downstreams).
>
> But again: You really (!) should not limit icmp traffic with such a
> general rule but instead limit only specific types of icmp (like
> echo-request), and maybe even block other types completely on the
> external interface (redirect, source quench, a few others).
>
> Most others are important for announcing problems on the packet route -
> like smaller MTU (path mtu discovery), unreachable destinations etc.
> Unselectively blocking or limiting them will result in a lot of
> timeouts and intermittent connection freezes which are hard to
> understand.


I removed the limiting yesterday so that I'm simply allowing icmp packets:

ACCEPT  all  all  icmp

It didn't help with my TCP Queuing problem but I'll leave it as-is
because I'm sure you're right about the problems it could cause.


>> > Please also try to find out if you're experiencing packet loss. If
>> > fragmented packets cannot be reassembled due to some packets lost,
>> > you will probably find connections freezing or going really slow.
>>
>> I will watch the output of ifconfig today to see if there are any RX
>> or TX errors.
>
> I almost expect you won't see any numbers there but instead see the
> counter of your limit rule rise during periods where you see the
> problems. TX and RX errors only catch layer 1 or layer 2 losses, you
> are probably experiencing packet loss at or above layer 3 (and I guess
> due to your limit rule).
>
> Maybe run a ping to a destination which you are having problems with,
> then reproduce the problem (with the network idle otherwise). You should
> see ping packets dropped only then.
>
> You can also ping with increasing packet sizes (see ping --help) and
> see when the packet becomes too big for path MTU. But instead lowering
> your MTU then, you should allow icmp-fragmentation-needed come through
> reliably. Lowering MTU only makes sense to stop overly fragmentation in
> the first place and optimize for a specific packet path (like traffic
> through one or multiple VPN tunnels) where fragmentation would
> otherwise increase latency a lot, or where icmp-frag-needed does not
> correctly work.


I'll try pinging today once the issue pops up.

- Grant

Re: [gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Grant]

>> Maybe run a ping to a destination which you are having problems with,
>> then reproduce the problem (with the network idle otherwise). You should
>> see ping packets dropped only then.
>>
>> You can also ping with increasing packet sizes (see ping --help) and
>> see when the packet becomes too big for path MTU. But instead lowering
>> your MTU then, you should allow icmp-fragmentation-needed come through
>> reliably. Lowering MTU only makes sense to stop overly fragmentation in
>> the first place and optimize for a specific packet path (like traffic
>> through one or multiple VPN tunnels) where fragmentation would
>> otherwise increase latency a lot, or where icmp-frag-needed does not
>> correctly work.
>
>
> I'll try pinging today once the issue pops up.


I'm seeing the issue again as usual but ping response times come back
normal at about 50ms.  I'll keep trying.

- Grant

[gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Kai Krakow]

Am Wed, 21 Sep 2016 10:43:39 -0700
schrieb Grant <emailgrant@gmail.com>:

> >> Maybe run a ping to a destination which you are having problems
> >> with, then reproduce the problem (with the network idle
> >> otherwise). You should see ping packets dropped only then.
> >>
> >> You can also ping with increasing packet sizes (see ping --help)
> >> and see when the packet becomes too big for path MTU. But instead
> >> lowering your MTU then, you should allow icmp-fragmentation-needed
> >> come through reliably. Lowering MTU only makes sense to stop
> >> overly fragmentation in the first place and optimize for a
> >> specific packet path (like traffic through one or multiple VPN
> >> tunnels) where fragmentation would otherwise increase latency a
> >> lot, or where icmp-frag-needed does not correctly work.  
> >
> >
> > I'll try pinging today once the issue pops up.  
> 
> 
> I'm seeing the issue again as usual but ping response times come back
> normal at about 50ms.  I'll keep trying.

Not sure if this came after or before switching your router to modem
mode... But if it happened before and is solved now, your router really
doesn't well with icmp packets or has problems with mss clamping / pmtu.


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Grant]

>> >> Maybe run a ping to a destination which you are having problems
>> >> with, then reproduce the problem (with the network idle
>> >> otherwise). You should see ping packets dropped only then.
>> >>
>> >> You can also ping with increasing packet sizes (see ping --help)
>> >> and see when the packet becomes too big for path MTU. But instead
>> >> lowering your MTU then, you should allow icmp-fragmentation-needed
>> >> come through reliably. Lowering MTU only makes sense to stop
>> >> overly fragmentation in the first place and optimize for a
>> >> specific packet path (like traffic through one or multiple VPN
>> >> tunnels) where fragmentation would otherwise increase latency a
>> >> lot, or where icmp-frag-needed does not correctly work.
>> >
>> >
>> > I'll try pinging today once the issue pops up.
>>
>>
>> I'm seeing the issue again as usual but ping response times come back
>> normal at about 50ms.  I'll keep trying.
>
> Not sure if this came after or before switching your router to modem
> mode... But if it happened before and is solved now, your router really
> doesn't well with icmp packets or has problems with mss clamping / pmtu.


I did not try pinging before switching the device from router to modem.

BTW, I read that setting CLAMPMSS=Yes in shorewall.conf is a necessity
when using PPPoE but my connection is working fine without that
setting.  Should I set it anyway?

- Grant

[gentoo-user] Re: {OT} ISP requires MTU below 1500?

[Kai Krakow]

Am Wed, 21 Sep 2016 12:32:48 -0700
schrieb Grant <emailgrant@gmail.com>:

>  [...]  
>  [...]  
> >>
> >>
> >> I'm seeing the issue again as usual but ping response times come
> >> back normal at about 50ms.  I'll keep trying.  
> >
> > Not sure if this came after or before switching your router to modem
> > mode... But if it happened before and is solved now, your router
> > really doesn't well with icmp packets or has problems with mss
> > clamping / pmtu.  
> 
> 
> I did not try pinging before switching the device from router to
> modem.
> 
> BTW, I read that setting CLAMPMSS=Yes in shorewall.conf is a necessity
> when using PPPoE but my connection is working fine without that
> setting.  Should I set it anyway?

If pmtu discovery is working correctly, this is - in theory - not
needed. It violates the protocol guarantees anyway. But it reduces
packet fragmentation with encapsulation protocols like pppoe (because
pppoe reserves some extra bytes of headers which reduces your amount of
payload per packet).

-- 
Regards,
Kai

Replies to list-only preferred.