ну я прокачал файл в 5 Гб за 15 минут с другого ноута успешно без каких либо проблем

значит надеемся, что косяк именно с тем ноутом

Если ipip/gre то собирается на втором конце туннеля

То есть зависит от типа туннеля, да? если PPPoE, скажем?

умеет. вплс, например, может собирать пакеты и именно на роутере :)

Через Mpls фрагментированный пакет не пойдёт

ну туннели понятно. Тут вопрос, насколько я понял, по чистой маршрутизации

и как вплс связан с туннелями? :)

То есть зависит от типа туннеля, да? если PPPoE, скажем?

Зависит от dst в пакете

значит надеемся, что косяк именно с тем ноутом

скорее всего так. на нем еще и линк вместо 2 х 2 подключается 1 х 2 и в результате аплоад быстрее даунлоада почти в 2 раза

скорее всего так. на нем еще и линк вместо 2 х 2 подключается 1 х 2 и в результате аплоад быстрее даунлоада почти в 2 раза

скачай драйвера новые под карту

Возьмем такой пример: Host A-> ethernet 1500 -> MikroTik -> PPPoE 1492 -> Any PPPoE router -> Ethernet -> Host B

Возьмем такой пример: Host A-> ethernet 1500 -> MikroTik -> PPPoE 1492 -> Any PPPoE router -> Ethernet -> Host B

TCP MSS = 1460. В этом случае пакет разбился на фрагменты на микротике и где будет конечная сборка в итоге ?

скачай драйвера новые под карту

там убунта - дрова уже в ядре из коробки

TCP MSS = 1460. В этом случае пакет разбился на фрагменты на микротике и где будет конечная сборка в итоге ?

а чо это он на микротике разбился то? согласование мту же должно было пройти

там убунта - дрова уже в ядре из коробки

может это и есть проблема 😂

а чо это он на микротике разбился то? согласование мту же должно было пройти

Ок, допустим вместо PPPoE -> IPSec ESP

TCP MSS = 1460. В этом случае пакет разбился на фрагменты на микротике и где будет конечная сборка в итоге ?

Нигде

Нигде

Т.е. пакет не разобьется?

Ок, допустим вместо PPPoE -> IPSec ESP

а какая разница то? pmtu же

ок, тогда я не совсем понимаю юзкейс mangle action=change-mss

Т.е. пакет не разобьется?

Пакет будет строится с учетом mtu 1460 на этапе формирования

ок, тогда я не совсем понимаю юзкейс mangle action=change-mss

Нужно для согласования размера сегмента

Пакет будет строится с учетом mtu 1460 на этапе формирования

MTU 1500 же, после PPPoE 1492

ну и если стоит галка change mss, то на всех пакетах, идущих транзитом чероз пппое в син пакете будет меняться соответствующий флаг на значении мсс

Нужно для согласования размера сегмента

Размера TCP сегмента L4? Или фрейма L2?

ну мсс же

ну и если стоит галка change mss, то на всех пакетах, идущих транзитом чероз пппое в син пакете будет меняться соответствующий флаг на значении мсс

Это я понимаю как микротик умеет вмешиваться в процесс согласования MSS. Допустим. Браузер посылает первоначальный syn пакет с MSS 1460. Как он его вычисляет? По MTU сетевой карты?

Это я понимаю как микротик умеет вмешиваться в процесс согласования MSS. Допустим. Браузер посылает первоначальный syn пакет с MSS 1460. Как он его вычисляет? По MTU сетевой карты?

Свой по мту аут интерфейса. Ответная часть присылает свой. Выбирается меньший

Размера TCP сегмента L4? Или фрейма L2?

Mss - определяет размер сегмента (l4), так чтобы оригинальный пакет, частью которого он является, помещался ip mtu (l3) без фрагментации.

Свой по мту аут интерфейса. Ответная часть присылает свой. Выбирается меньший

Воот, ответка присылает свой, браузер начинает обмен на меньшей из двух. Допустим: браузер отправляет 1460, сервер 1420 - рабочий MSS для TCP сессии будет 1420. Но если по пути где-то встречается IPSec транзит с MTU 1400, какой будет результирующий MSS

Воот, ответка присылает свой, браузер начинает обмен на меньшей из двух. Допустим: браузер отправляет 1460, сервер 1420 - рабочий MSS для TCP сессии будет 1420. Но если по пути где-то встречается IPSec транзит с MTU 1400, какой будет результирующий MSS

1420. И Сборка по идее будет на dst устройстве

1420. И Сборка по идее будет на dst устройстве

То есть фрагментация IP пакетов случится на входе в IPSec транзит и мелкая дробь полетит уже на ответку, верно?

То есть фрагментация IP пакетов случится на входе в IPSec транзит и мелкая дробь полетит уже на ответку, верно?

Погоди...

и если эта дробь попадется на еще один IPSec транзит, где ей снова предстоит фрагиментация, то крупные куски снова попадут на измельчение

То есть фрагментация IP пакетов случится на входе в IPSec транзит и мелкая дробь полетит уже на ответку, верно?

IPSec будет инкапсулировать пакет. При выходе из инкапсуляции пакет должен собраться в исходный

и если эта дробь попадется на еще один IPSec транзит, где ей снова предстоит фрагиментация, то крупные куски снова попадут на измельчение

Выше смотри

и тут задача сетевого инженера на транзитных туннелях оказывать содействие TCP сессиям на недопущение MSS выше MTU-40 на входе в транзит

я просто слайды пилю для MUM и надо придумать как это нарисовать для “самых маленьких“ 🙂

IPSec будет инкапсулировать пакет. При выходе из инкапсуляции пакет должен собраться в исходный

то есть сам микротик займется сборкой разбитых на фрагменты IPSec пакетов

то есть сам микротик займется сборкой разбитых на фрагменты IPSec пакетов

Да. Потому что dst address при попадании IPSec транзита будет выходной микрот.

С IPSec понятно, а если PPPoE / PPTP / L2TP

С IPSec понятно, а если PPPoE / PPTP / L2TP

То инкапсуляции не будет. А фрагментация будет. И Сборка уже на адресе назаначения будет

Как вычисляется MSS?

То инкапсуляции не будет. А фрагментация будет. И Сборка уже на адресе назаначения будет

Тогда поясни плиз про Path MTU discovery - не совсем понимаю его работу

Браузер знает MTU рабочего интерфейса 1500, посылает MSS 1460

Тогда поясни плиз про Path MTU discovery - не совсем понимаю его работу

Пинг до dst с df и до src с df. Минимальный фрагмент высчитывается и меняется в синк пакете mss

Пинг до dst с df и до src с df. Минимальный фрагмент высчитывается и меняется в синк пакете mss

Брутфорсит? 🙂

Как вычисляется MSS?

Это понятно

1) пинги буквально отдельными пакетами летят перед установлением TCP сессии? 2) Пинги разных размеров до поиска максимально подходящего?

Брутфорсит? 🙂

@insoln призываем

На этот вопрос Михаил Москалев на MTCUME так и не смог ответить внятно, потому остался пробел )

@moneron

в мангле есть action=change-mss new-mss=“clamp to pmtu” - кто может рассказать как это работает?

в мангле есть action=change-mss new-mss=“clamp to pmtu” - кто может рассказать как это работает?

Это значит будет изменять мсс так: path_MTU - 40 для IPv4; -60 для IPv6

Это значит будет изменять мсс так: path_MTU - 40 для IPv4; -60 для IPv6

Как микротик вычисляет этот pmtu между собеседниками?

@insoln призываем

уже лечу

Как микротик вычисляет этот pmtu между собеседниками?

При мангле используется значение мту на ptp интерфейсе. А его в свою очередь вычисляет от мту интерфейса через который строитс ptp вычитая заголовки протокола

уже лечу

Отлично. Ждём

При мангле используется значение мту на ptp интерфейсе. А его в свою очередь вычисляет от мту интерфейса через который строитс ptp вычитая заголовки протокола

по сути микротик отвечает только за свой участок, верно? Снижает MSS до наименьшего из участвующих в обмене интерфейсов. Это точно имеет отношение к PMTU ?

При мангле используется значение мту на ptp интерфейсе. А его в свою очередь вычисляет от мту интерфейса через который строитс ptp вычитая заголовки протокола

Под собеседниками я имел в виду именно конечные узлы

по сути микротик отвечает только за свой участок, верно? Снижает MSS до наименьшего из участвующих в обмене интерфейсов. Это точно имеет отношение к PMTU ?

Была практика когда строил gre с флагом pathmtu. Так вот. На разных сторонах были разные по мту интерфейсы. Микрот вычислил mtu gre на каждой стороне свой. Между собой не согласовал.

по сути микротик отвечает только за свой участок, верно? Снижает MSS до наименьшего из участвующих в обмене интерфейсов. Это точно имеет отношение к PMTU ?

нет, pmtu - это поведение оконечника

@insoln призываем

Cumberbatch Wikipedia For IPv4 packets, Path MTU Discovery works by setting the Don't Fragment (DF) flag bit in the IP headers of outgoing packets. Then, any device along the path whose MTU is smaller than the packet will drop it, and send back an Internet Control Message Protocol (ICMP) Fragmentation Needed (Type 3, Code 4) message containing its MTU, allowing the source host to reduce its Path MTU appropriately. The process is repeated until the MTU is small enough to traverse the entire path without fragmentation.

то есть первый пакет если пролетает маршрут - значит все хорошо если нет, то не пропускает, но отвечает ICMP ответом сколько можно на его участке. И так снижае по кругу, пока все все помехи не будут пройдены до конечника. Этот PMTU работает судя по всему автоматически и только при условии, что нигде не режутся ICMP пакеты

correct

еще может быть доп.поведение - периодически пробовать приподнять мту

но на этот самый PMTU в ip4 расчитывать не стоит и лучше помогать TCP сессиям работать на заранее посчитанном MSS

но на этот самый PMTU в ip4 расчитывать не стоит и лучше помогать TCP сессиям работать на заранее посчитанном MSS

так как ICMP может быть отфильтрован между узлами на транзитах

correct

а какая разница то? pmtu же

читай ответ выше )

пмту в современных системах, кстати, работает в отрыве от tcp

то есть изначально это зародилось как фича tcp, а потом и н все остальное натянули в стеке

correct

есть ли смысл принудительно снижать MSS для IPSec ike2 roadwarrior до 1360?

если мту 1400 (по бестпрактисам), то 1360 выглядит разумно

то есть изначально это зародилось как фича tcp, а потом и н все остальное натянули в стеке

как убедиться, что трафик PMTU не фильтруется микротиком?

посмотреть правила файрвола?

если мту 1400 (по бестпрактисам), то 1360 выглядит разумно

МакОС точно выставляет MTU 1400 на ipsec0 “интерфейсе”

я с гейбуками на вы

посмотреть правила файрвола?

эти icmp ответы они попадают в established & related правила?

ну и ике не моя сильная тема

я с гейбуками на вы

в винбуках тоже 1400?