MikroTik и странности с MTU


Произошла со мной недавно проблема, которая заставила повозиться с сетью некоторое время. Суть проблемы заключалась в том, что доступ в Интернет через роутер MikroTik был каким-то немного подбитым: без лишних проблем открывались все сайты, работающие по IPv4, но с IPv6 непонятки — часть ресурсов открывалась без каких-либо проблем, часть не открывалась вообще, а некоторые открывались через раз по пятницам. При этом никаких потерь на IPv6-интерфейсе не было, на первый взгляд всё было хорошо.

Тут ещё надо отметить, что IPv6 местные провайдеры как таковой практически не обеспечивают. Грубо говоря, на большой город есть только два провайдера с нативным IPv6 — одни дают лишь один IPv6-адрес /128 на роутер (в итоге дальше всё работает через NAT и современные протоколы, такие как QUIC, успешно руинятся, т.е. пользы от такого IPv6 в целом я не вижу), вторые — вроде бы сеть /64, но имеют покрытие сети размером в полтора дома. Конкретно на данной точке включения у меня работает 6in4-туннель, что тоже вносит некоторые коррективы в работу с IPv6: временами провайдер теряет маршрут до конечной точки туннеля и всё прекращает работать насовсем до восстановления, а иногда до конечной точки наблюдается дикий packet loss, благодаря чему IPv6 работает кое-как, скорее для галочки.

MTU MikroTik, в принципе, определяет адекватно и в автоматическом режиме, без необходимости что-либо вручную корректировать.
В данном случае мы имеем MTU 1500 на порту, через который осуществляется соединение с оборудованием провайдера; MTU -20 на PPPoE-интерфейсе, через который до провайдера непосредственно проходит трафик; и ещё -20 к MTU получаем на этапе подключения туннеля.
Итого, размер максимальной перемещаемой посредством IPv6 единицы у нас будет составлять 1460 байт, а по IPv4 — 1480 байт.
Эти настройки MikroTik определил автоматически, мне ничего не потребовалось менять.

Если честно, попинговав IPv6-ресурсы пакетами по 1460 байт и получив от них корректные ответы я успокоился да и забил на некоторое время на этот вопрос, приняв проблемы за временные глюки в коммуникации с конечной точкой туннеля. Так бы всё, наверное, и осталось, если бы я не заменил MTU на одном из серверов, с которым нужно быть в контакте той сети, на которой установлен MikroTik, с 1400 на 1500. Удивительным образом связь с этим сервером по IPv6 пропала. Тут уж я понял, что нужно разбираться более детально.

Как выяснилось при диагностике, если проверять с самого роутера — то всё отлично. Но вот при попытке обратиться к какому-либо ресурсу с подключенных к сети клиентов по IPv6 происходит проблема — MTU слишком высок и не проходит через схему, указанную на картинке выше. Тут я столкнулся с некоторой проблемой, т.к. если в компьютере я могу вручную задать MTU интерфейсу, то с устройствами, которые не поддерживают столь детальной настройки сети (IP-телефон, телевизор, приставка и т.п.) как поступать — непонятно.

После непродолжительных исследований оказалось, что в MikroTik можно задать MTU для клиентов, которые получают свои IPv6-адреса посредством ND. А это как раз тот случай, который мне и был нужен. Указание в настройках Neighbor Discovery MTU, равного MTU 6in4-туннеля, помогло решить эту проблему и действительно через некоторое время все клиенты, подключённые к данной сети, получили корректные настройки, с которыми всё стало работать как надо, без проблем с MTU.

Проблема показалась мне достаточно интересной, так как, как правило, во всех сетях, с которыми я работал, PPPoE уже не использовалось. Соответственно, не возникала потребность срезания дополнительных 20 байт под заголовки PPPoE из-за чего ни разу не требовалось дополнительно оповещать клиентов о том, что работа по IPv6 требует иного MTU, нежели работа по IPv4.


Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *