09 Feb 22 13:37, Eugene Grosbein wrote to Dmitriy Smirnov:
DS>> вот, detection и включил, только вот может у этого решения есть DS>> свои подводные камни.
EG> Есть: подбор таймаутов при перепосылках между разными уровнями EG> "плато", а так же рост таблицы соответствий IP/MTU и подбор таймаута EG> устаревания данных в таблице.
т.е. менее "геморройная" схема на отправляющей стороне выставить, например, минимальный MTU 1280 и мириться с тем, что IPv6 будет медленнее бегать, но при этом будет всё же бегать там где он впринципе сможет бегать?) я читал статейку cloudflare про их опыт по этой части, смотрели процент клиентов с тем или иным мту и подбирали оптимальный, после конечно еще накатали свой софт PMTUD (на гитхабе в исходниках доступен).
DS>> зы: я уж думал, что пляски с mtu ушли в историю со времен IPv4, DS>> ан нет, все еще актуально даже с IPv6 =)
EG> С IPv6 даже хуже, потому что там минимальный MTU задрали сильно. EG> Hа плохих линках типа 3G (Yota etc.) с ненулевым процентом потерь EG> я всегда достигал бОльшей стабильности VPN-туннелей, EG> занижая MTU до 576 - пакет меньшей длины пролазит с большей EG> вероятностью, а при потерях меньше перепосылать. В IPv6 минимальный EG> размер вдвое больше.
да, на уских тоннелях про в6 с её 1280 и не приходится говорить %)
