Я вижу ICMP-шторм от сетевых блоков мобильного телефона, принадлежащих "TELEFONICA MOVILES". Периодически мы получаем более 5 миллионов за несколько секунд, все примерно так:
08: 12: 05.740781 IP (tos 0x0, ttl 112, id 40224, смещение 0, флаги [none], proto ICMP (1), длина 56) 200.76.88.6> ABCD: ICMP 200.39.21.96 недоступен - необходимо фрагментировать (mtu 250), длина 36
("A.B.C.D" - мой ip)
Можно ли вообще использовать MTU в 250 или разрешить его? 68? Эти ICMP связаны с более серьезными проблемами с нашей стороны, но я не могу сказать, являются ли они симптомом, причиной или просто совпадением.
Что в этом случае делает алгоритм обнаружения MTU пути? Сервер - FreeBSD 7.
MTU в 68 байт действительно в IPv4 в соответствии с RFC 791:
Каждый интернет-модуль должен иметь возможность пересылать датаграмму из 68 октетов без дальнейшей фрагментации. Это связано с тем, что заголовок Интернета может иметь длину до 60 октетов, а минимальный фрагмент - 8 октетов.
Требования к поддерживаемым размерам в собранном виде намного больше:
Каждое место назначения в Интернете должно иметь возможность получать дейтаграмму из 576 октетов либо целиком, либо фрагментами для повторной сборки.
В IPv6 эти числа были увеличены до 1280 и 1500 байтов, как указано в RFC 2460:
IPv6 требует, чтобы каждая ссылка в Интернете имела MTU не менее 1280 октетов. На любом канале, который не может передать пакет размером 1280 октетов одним фрагментом, специфичная для канала фрагментация и повторная сборка должны быть обеспечены на уровне ниже IPv6.
Узел должен иметь возможность принимать фрагментированный пакет, размер которого после повторной сборки достигает 1500 октетов. Узлу разрешено принимать фрагментированные пакеты, размер которых превышает 1500 октетов. Протокол или приложение верхнего уровня, которые зависят от фрагментации IPv6 для отправки пакетов, размер которых превышает MTU пути, не должны отправлять пакеты размером более 1500 октетов, если у него нет гарантии, что пункт назначения способен повторно собрать пакеты этого большего размера.
Если кому-то интересно, вот что я нашел.
Короткий ответ: нет, эти небольшие MTU недопустимы, но FreeBSD 7 и 8 должны лучше справиться с ситуацией, поскольку некоторые изменения кода были внесены примерно в конце августа.
В этом отчете о проблеме есть еще: http://www.freebsd.org/cgi/query-pr.cgi?pr=146628
Обнаружение MTU пути не сбрасывало флаг «не фрагментировать», что означает, что упрямый хост с плохим поведением на другой стороне будет продолжать посылать шторм недостижимых сообщений «требуется фрагмент». Теперь после получения первого крошечного MTU DF очищается, что эффективно перемещает проблему вниз по течению к маршрутизатору, ближайшему к нарушителю. (Так как им придется сделать за преступника абсурдные фрагменты.)