Hash: SHA256

Hi Stuart,

On 09/16/16 14:08, Stuart Henderson wrote:
> On 2016-09-14, Harald Dunkel <ha...@afaics.de> wrote:
>> 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 whatever.
> 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 some sites.

Would you say that setting "scrub (no-df random-id)" is best practice
for IPv4 traffic forwarded into the internet?

> 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).

I figured this out, but maybe pf.conf(5) could be more explicit on
this detail, too?

> 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.

Deutsche Telekom seems to support baby jumbo frames ("Dumbos"? :-) )
on my side, but they told me that they don't actively support per-
customer MTUs on their BNGs.

Thanx for your detailed response. That was really helpful.




Reply via email to