On 2016-09-14, Harald Dunkel <ha...@afaics.de> wrote:
> Hi folks,
> On 09/13/2016 02:58 PM, Stuart Henderson wrote:
>> See "MTU/MSS ISSUES" in pppoe(4).
> indeed, its documented, but its also a little bit misleading.
> Reading the man page I had the first impression that modifying
> the mtu and max-mss are equally effective. Apparently they
> are not.
> AFAIU setting the max-mss affects TCP traffic only (e.g.
> HTTPS). It defines the maximum payload block size on sending
> and receiving(!) data via TCP. UDP and other protocols are not
> affected. Very important to know if you run IPsec or openvpn
> or other non-TCP protocols over the PPPoE tunnel.
> The mtu works on ethernet level, giving the maximum packet
> size to send(!) to the next hop without fragmentation,
> regardless if the higher level protocol is TCP, UDP, ESP or
You are supposed to be able to get large packets through; routers
are meant to either fragment or send ICMP "frag-needed" messages
to allow the end host to do it. But some idiots misconfigure their
firewalls to drop the necessary ICMP messages causing breakage to
In practice, people configuring non-TCP services often try to keep
packets below the common breakage points (especially 1492)..
> Point is, setting the MTU does not affect the data flow from
> the peer back to your site. AFAIU this made the difference
> in this case. Reducing the max-mss seems to be a workaround
> for some networking issue I cannot fix.
The MSS in the TCP handshake is based on the MTU on the outgoing
route from the end host. So if you have
router - pppoe0 - 1492
router - internal - 1500
host - internal - 1500
the host will base its calculation on 1500 not 1492.
"scrub (max-mss ..)" will cap this in the TCP handshake (and adjust
checksums to match).
However: if you have working 1500 MTU pppoe via baby jumbos on
the ethernet interface, "scrub (max-mss..)" shouldn't fix anything.
The restricted MTU is usually towards the "client" side of things
rather than towards the server, plus if it's towards the server
then many people will be affected so it's easier for the server
admin to spot problems.
> My current configuration uses both baby jumbo frames (mtu = 1508
> on re0 and mtu = 1500 on pppoe0) and "scrub (max-mss 1452)" for
> TCP traffic on pppoe0 (1500 bytes - 40 bytes TCP/IP header -
> 8 bytes PPPoE frame).
You should not need both. If baby jumbos are working correctly
(you can "ping -D -s 1472 $some_internet_host" from an end host)
then you should be able to get rid of the scrub. If they are not
working correctly, you should get rid of the baby jumbo config
and just use 1492, this will at least fix things for larger
packets in the normal case where there is no bad firewall config
in the way.