[boss-chifra]

Есть железка которая шлет фрагментированные UDP пакеты, на железке MTU 1500, больше она не может.

Когда ей нужно передать блок данных на 2500 байт она шлет этот один блок данных в 2 пакетах, тоесть как бы пакет один но из 2 сегменртов на 1500 и 1000 байт.

Сеть у нас большая и на конечном отрезке пути  маршрутизатор имеет MTU 9000 на обоих сторонах(да нам это нужно, почему нет?).

Это приводит к тому что конечный маршрутизатор Linux принимает эти 2 сегмента и так как у него MTU 9000 он уже отправляет далее один пакет на 2500 байт.

К сожалению принимающая железка не может принять пакет так как у нее 1500 MTU. (black hole hello)

 

Вопрос, есть какие-то варианты запретить маршрутизатору Linux собирать пакет из сегментов? Кто-то вообще встречался с такой проблемой что какой-то софт шлет фрагментированные пакеты которые могут собраться где то в сети хотя сам этот софт не умеет принимать такие собранные пакеты (у нас это проблема с Wi-Fi точками и их контроллером управления)

[edo]

1 час назад, boss-chifra сказал:

MTU 9000 на обоих сторонах(да нам это нужно, почему нет?).

хотя бы потому, что у этого хоста будут проблемы со связью с другими хостами.

hint: на каждый vlan можно назначить свой mtu, поделите сети и будет вам счастье.

 

 

 

вдогонку: несколько секунд гугления говорят, что так просто задача не решается:

https://unix.stackexchange.com/questions/305280/disable-ip-fragment-reassembly-in-forwarded-datagrams/305295

https://serverfault.com/questions/994677/how-to-selectively-disable-ip-reassembly

[Ivan_83]

Мне вспоминается что у линукса вроде можно было маршруты с mtu делать.

Может вам поможет отключение аппаратных оффлоадингов на сетевухах.

[boss-chifra]

> хотя бы потому, что у этого хоста будут проблемы со связью с другими хостами
у других хостов тоже 9000 и проблем нет, если у нас в сети используется 9000 и из-за одной так сказать паршивой овцы перекраивать сеть странно.

 

> на каждый vlan можно назначить свой mtu, поделите сети и будет вам счастье.
да это хорошее предложение и как его реализовать пока не ясно, конечно у нас есть куча vlan и все поделено но они все на свиче и вот как настроить  на свиче MTU что-бы он отвечал ICMP пакетам на не возможность послать пакет размером 2000 в vlan для которого 1500 максимум не ясно. У нас используются свичи HPE 5130 или HPE 5920

> вдогонку: несколько секунд гугления говорят, что так просто задача не решается:

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

> Может вам поможет отключение аппаратных оффлоадингов на сетевухах.
не понимаю технически как это может повлиять

> Мне вспоминается что у линукса вроде можно было маршруты с mtu делать.
да верно это единственное что мы смогли сделать, но это для нас не подходит так как маршруты со свича приходят по OSPF и переписывать их статикой не хорошее занятие.

А в OSPF не найдено что то что управляет MTU для маршрктов

[dr Tr0jan]

14 minutes ago, boss-chifra said:

да это хорошее предложение и как его реализовать пока не ясно, конечно у нас есть куча vlan и все поделено но они все на свиче и вот как настроить  на свиче MTU что-бы он отвечал ICMP пакетам на не возможность послать пакет размером 2000 в vlan для которого 1500 максимум не ясно. У нас используются свичи HPE 5130 или HPE 5920

А вам не надо настраивать MTU на свитче, дефрагментацией же маршрутизатор занимается.

Вам нужно железяки (не умеющие jumbo) изолировать в отдельном (отдельных виланах) и на маршрутизаторе в этом вилане (виланах) отключить jumbo.

[boss-chifra]

2 hours ago, dr Tr0jan said:

А вам не надо настраивать MTU на свитче, дефрагментацией же маршрутизатор занимается.

Вам нужно железяки (не умеющие jumbo) изолировать в отдельном (отдельных виланах) и на маршрутизаторе в этом вилане (виланах) отключить jumbo.

все железо сервера подключены в свитч HPE который для них и является маршрутизатором (default gw) и рулит vlan, а Linux Router о кототором речь является звеном связи с другими офисами и у него один интерфейс который смотрит на свич HPE. И так как у нам нужно между офисами Jumbo  поэтому у межофисного Linux Router оба интерфейса 9000. И он как раз и собирает из фрагменов пакет и пуляет его в HPE
А HPE хоть и роутер но видимо не настоящий так как невозможно ему никак сказать какие у него MTU на разных VLAN, он тупо все считает jumbo и пропускает.

[rm_]

1 hour ago, boss-chifra said:

у него один интерфейс который смотрит на свич HPE.

На этом интерфейсе у Linux-роутера и поднять два VLAN'а, один с джамбо другой без.

И всё увести в эти вланы, untagged трафика у роутера со свитчем больше быть не должно.

Можно и без последнего (во VLAN перевести только неджамбо-трафик), но это криво и лучше не надо так.

[edo]

1 час назад, boss-chifra сказал:

А HPE хоть и роутер но видимо не настоящий

вот-вот.

моё ИМХО: роутинг в свитчах в большинстве случаев вовсе не нужен.

 

12 минут назад, rm_ сказал:

Можно и без последнего (во VLAN перевести только неджамбо-трафик), но это криво и лучше не надо так.

у меня весь трафик тегированный, а в untagged управление свитчами. может быть и зря, когда настраивал, показалось, что так будет меньше телодвижений.

 

4 часа назад, boss-chifra сказал:

> Может вам поможет отключение аппаратных оффлоадингов на сетевухах.
не понимаю технически как это может повлиять

оффлоад может собирать фрагментированные пакеты, так что даже если вы сможете включить в ядре пересылку фрагментов, ничего не изменится.

[krux]

--clamp-mss-to-pmtu

разве нет?

[boss-chifra]

On 12/25/2020 at 6:00 PM, rm_ said:

На этом интерфейсе у Linux-роутера и поднять два VLAN'а, один с джамбо другой без.

И всё увести в эти вланы, untagged трафика у роутера со свитчем больше быть не должно.

Можно и без последнего (во VLAN перевести только неджамбо-трафик), но это криво и лучше не надо так.

да вы правы идею поднятия vlan с установленным в нужное значение на Linux роутере я не думал но похоже это может решить проблему, кривовато но решение.

 

> моё ИМХО: роутинг в свитчах в большинстве случаев вовсе не нужен.

 

ну когда у нас сотня vlan то не правильно работоспособность и связность сегментов зачем-то завязывать на Linux роутер. Стек свичей надежнее и по скорости быстрее, поэтому ядро сети сделано HPE.

 

> --clamp-mss-to-pmtu

это всего лишь работа с MSS у TCP а проблема с UDP

[rm_]

1 hour ago, boss-chifra said:

да вы правы идею поднятия vlan с установленным в нужное значение на Linux роутере я не думал но похоже это может решить проблему, кривовато но решение.

Кривовато - это когда в одной и той же сети (в одном VLAN'е) без роутинга сосуществуют хосты с разным MTU.

Разделить их вот так на разные VLAN'ы видится вполне нормальным.

[sol]

Ну и поставьте какой нибудь линукс роутер о двух интерфейсах на пути к проблемным штукесам. С разным MTU на интерфейсах. Он вам и разберёт jumbo на пакеты "классического" размера.

Хоть Raspberry PI, хоть китаёзу какую нибудь, хоть прости Господи Микротик. Хотя я не уверен что последний умеет Jumbo. Но, сейчас Мэтр на ключевое слово наведётся, прибежит и расскажет.

 

[myst]

13 минут назад, sol сказал:

Ну и поставьте какой нибудь линукс роутер о двух интерфейсах на пути к проблемным штукесам. С разным MTU на интерфейсах. Он вам и разберёт jumbo на пакеты "классического" размера.

Хоть Raspberry PI, хоть китаёзу какую нибудь, хоть прости Господи Микротик. Хотя я не уверен что последний умеет Jumbo. Но, сейчас Мэтр на ключевое слово наведётся, прибежит и расскажет.

 

Еретик! Надо ставить ДВА микротика. =)

 

[boss-chifra]

14 hours ago, rm_ said:

Кривовато - это когда в одной и той же сети (в одном VLAN'е) без роутинга сосуществуют хосты с разным MTU.

Разделить их вот так на разные VLAN'ы видится вполне нормальным. 

Так у нас так и есть, и таким разделителем является HPE который держить много много VLAN но он не умеет определять какой MTU где и тупо пуляет пакеты без проверки пролезают они или нет.

Поэтому ваше предложение роутить это не на ядре а на отдельном Linux который может проверть MTU и является рабочим решением но кривоватым

 

4 hours ago, sol said:

Ну и поставьте какой нибудь линукс роутер о двух интерфейсах на пути к проблемным штукесам. С разным MTU на интерфейсах. Он вам и разберёт jumbo на пакеты "классического" размера.

Хоть Raspberry PI, хоть китаёзу какую нибудь, хоть прости Господи Микротик. Хотя я не уверен что последний умеет Jumbo. Но, сейчас Мэтр на ключевое слово наведётся, прибежит и расскажет.

 

ну конечно не микротик, но боль что дорогущие свичи HPE не могут простого и для того что-бы роутить пакеты из одного VLAN где есть jumbo в тот в котором такого нет, нужно делать отдельный роутер на Linux подобной OS, я плакать.

[dr Tr0jan]

@boss-chifra, у вас проблема не в дорогущем HPE, а в звене HPE-Linux роутер. Это даже не проблема, а нормальная работа.

Каталисты 9500, например, себя также ведут, если не хуже.

[boss-chifra]

11 minutes ago, dr Tr0jan said:

@boss-chifra, у вас проблема не в дорогущем HPE, а в звене HPE-Linux роутер. Это даже не проблема, а нормальная работа.

Каталисты 9500, например, себя также ведут, если не хуже.

а можно узнать в чем проблема со свеном HPE-Linux роутер ?
в каждом офисе есть ядро сети с кучей vlan и на HPE, что-бы сделать связть между офисами(выпустить офис в интренет) нужно что-то еще и для этого используется Linux роутер.

Тоесть трафик из одного офиса в другой идет по пути железка1->HPE(ядро офиса1)->Linux роутер(офиса1)-> VPN(или интернет)->Linux роутер(офиса2)->HPE(ядро офиса2)-> железка2

 

И вот связка Linux роутер(офиса2)->HPE(ядро офиса2) на MTU9000 так как HPE(ядро офиса2) имеет много vlan где прекрасно работает MTU9000 и отключать это не хочется

Почему простая вещь для HPE проверить что в конкретном Vlan нет поддержки 9000 кажется такой сложной если любой Linux роутер за 100$ это может искаропки, просто ответить Linux роутеру (офиса2) ICMP (need to frag (mtu 1500)) ??? рыдаю

 

[dr Tr0jan]

30 minutes ago, boss-chifra said:

а можно узнать в чем проблема со свеном HPE-Linux роутер ?

В том, что у вас на этом участке jumbo разрешены, а вы туда хотите фрагментированные пакеты слать.

31 minutes ago, boss-chifra said:

что-бы сделать связть между офисами(выпустить офис в интренет) нужно что-то еще и для этого используется Linux роутер.

А какая необходимость, использовать jumbo между офисами? Хотя не спорю, что подобная проблема может иметь место в схемах router-on-stick. Но как раз в таких ситуациях данную проблему имеет смысл решать двумя виланами (один для 1500, другой для jumbo).

34 minutes ago, boss-chifra said:

Почему простая вещь для HPE проверить что в конкретном Vlan нет поддержки 9000

Как вы оценили простоту вещи? Да и HPE - скорее всего L3-коммутатор, а не роутер. Меня вона в соседней теме активно убеждали отказаться от NAT в шеститоннике, отказался.

[YuryD]

1 час назад, boss-chifra сказал:

ну конечно не микротик, но боль что дорогущие свичи HPE не могут простого и для того что-бы роутить пакеты из одного VLAN где есть jumbo в тот в котором такого нет, нужно делать отдельный роутер на Linux подобной OS, я плакать.

 С каких пор свитчи стали маршрутизаторами ? Или это просто свитч, или маршрутизатор, или кастрированный маршрутизатор+свитч с избытком интеллекта в куцых мозгах. Примеров полно, от блинка до мокротика.

[boss-chifra]

17 minutes ago, dr Tr0jan said:

В том, что у вас на этом участке jumbo разрешены, а вы туда хотите фрагментированные пакеты слать

на участке HPE-Linux роутер  да разрешены Jumbo что-бы между офисам работал Jumbo и не вижу никаких проблем, да там могут быть или фрагментированные пакеты или полные Jumbo и тоже не понимаю чем это плохо.

А проблема в том что HPE приняв Jumbo не может понять что vlan назначения не поддерживает Jumbo и нужно ответить отправителю ICMP (need to frag (mtu 1500))

 

21 minutes ago, dr Tr0jan said:

А какая необходимость, использовать jumbo между офисами?

по заверениям разрабов малина 4 на сетевой имеет предел в pps и что-бы её разкачать нужно пакетики по больше слать и не упираться в pps  (малина нужна как доступный arm64)

25 minutes ago, dr Tr0jan said:

Да и HPE - скорее всего L3-коммутатор, а не роутер

цена у него не балуй и acl в нем есть значит его можно использовать как роутер, ну там OSPF и другие плюшки.

https://h20195.www2.hpe.com/v2/GetDocument.aspx?docname=c05158726&doctype=quickspecs&doclang=EN_US&searchquery=&cc=in&lc=en#
HPE FlexFabric 5940 Switch Series в доке большое перечисление Layer 3 routing фич

 

25 minutes ago, YuryD said:

Примеров полно, от блинка до мокротика.

ну микротик я как раз люблю за идеальное решение цена качество, и все минусы ему прощаю за цену

[sol]

2 часа назад, boss-chifra сказал:

но боль что дорогущие свичи HPE не могут простого и для того что-бы роутить пакеты из одного VLAN где есть jumbo в тот в котором такого нет, нужно делать отдельный роутер на Linux подобной OS, я плакать. 

Дело в том, что L3 коммутатор НЕ ЯВЛЯЕТСЯ РОУТЕРОМ. Это просто Ethernet коммутатор с дополнительными функциями. Он не может аппаратно разбивать большие пакеты на маленькие, ведь для этого надо менять много протокольных заголовков и вообще сделать из одного пакета условно два. Зато коммутатор может с бешеной скоростью перекладывать пакеты с помощью аппаратуры, а не процессора из порта в порт. И опционально менять ажно два заголовка (MAC отправителя и ttl). Причём, ttl только декрементировать, а MAC отправителя менять на один и тот-же, заранее известный.

 

А вот в пику L3 коммутатору роутер (как правило, программный) может делать что угодно. Он программный, сложность проделываемой работы определяется его программой. Он может выполнять даже такие сложные и экзотические действия как трансляция адресов (NAT) или балансировка нагрузки на HTTP сервер.

Предвидя комментарии сразу оговорюсь что _маршрутизаторы_ типа ASR1000 тоже программные. Их QFP представляет собой своего рода "сетевую видеокарту". Это массив вычислительных ядер (работающих по загружаемой программе) с аппаратной поддержкой затратных операций типа lookup и крипты.

 

В целом, требовать от L3 коммутатора умения менять MTU сродни сетованию на отсутствие в нём NAT, с мотивацией тем, что в любой Тенде или ТП-Линке за 1000р в розницу NAT таки есть.

[YuryD]

1 час назад, boss-chifra сказал:

А проблема в том что HPE приняв Jumbo не может понять что vlan назначения не поддерживает Jumbo и нужно ответить отправителю ICMP (need to frag (mtu 1500))

 С какого попугая коммутатор должен подменять-слать пакеты в порты, не относящиеся к его  управлению, если он L2 то выше ему делать нечего, мозгов не хватит. И эти байки про l3 коммутаторы - это в жопу маркетологам. ждамбофреймы не имеют к l3 никакого отношения, только  к l2.

[boss-chifra]

А вы точно меня слышите? я не прошу никакие

>"аппаратно разбивать большие пакеты на маленькие"

Я прошу простого принять пакет что он и так делает и ответить отправителю ICMP need to frag (mtu 1500)  что скажет что пакет не проолазит в vlan так как там нельзя большие пакеты.

он 100% принимает пакет как L3 так как он его будет маршрутизировать в другую сеть и он знает размер пакета и он мог-бы ответить отправителю ICMP как он это делает при обращении к несуществующим IP

[sol]

31 минуту назад, boss-chifra сказал:

А вы точно меня слышите?

Да, слышу. Ситуация с точностью до наоборот. Вы не слышите...

 

32 минуты назад, boss-chifra сказал:

Я прошу простого принять пакет что он и так делает и ответить отправителю ICMP need to frag (mtu 1500)

Дело в том, что L3 коммутатору НЕЧЕМ это делать.

Отсутствует такой аппаратный блок. Транзисторов в ASIC недосЫпали.

 

33 минуты назад, boss-chifra сказал:

он 100% принимает пакет как L3 так как он его будет маршрутизировать в другую сеть

Горькая правда жизни состоит в том, что L3 коммутатор не маршрутизирует пакеты... Он их коммутирует... Он просто меняет в пакете 13 байт, из которых один он уменьшает на единицу, другие 6 заменяет на 6 заранее известных а другие 6 меняет на те, которые ищет и находит в таблице смежности, после чего выпинывает пакет из нужного порта. Ну и CRC пересчитывается само на конечном автомате, отвечающем за логику порта.

 

39 минут назад, boss-chifra сказал:

и он мог-бы ответить отправителю ICMP как он это делает при обращении к несуществующим IP

Не мог бы. Нечем.

 

 

 

[boss-chifra]

Тоесть вы хотите сказать что он может все, от OSPF до BGP и acl на L3 а размер пакета он не может определить? не верю!

он уже может отвечать ICMP Frag needed and DF set (mtu = 1500) при пинге в не существующий IP (192.168.160.2 это HPE) а 192.168.160.2 не существующий IP

пингую из соседней сети (vlan)

> Нечем
Получается есть чем

 

ping -s 1600 -M do 192.168.160.1
PING 192.168.160.1 (192.168.160.1) 1600(1628) bytes of data.
From 192.168.160.2 icmp_seq=1 Frag needed and DF set (mtu = 1500)

 

Изменено 30 декабря, 2020 пользователем boss-chifra

[sol]

37 минут назад, boss-chifra сказал:

Тоесть вы хотите сказать что он может все, от OSPF до BGP

Это протоколы более высокого уровня. Их отрабатывает процессор. То, что вы ходите получить не доходит до уровня процессора и обрабатывается аппаратурой. Модель OSI слышали?

 

38 минут назад, boss-chifra сказал:

и acl

Очень простая аппаратная ф-ция. Надо смотреть на определённые биты по битовой же маске. Может. Всё сводится к нескольким аппаратным логическим операциям.

 

38 минут назад, boss-chifra сказал:

а размер пакета он не может определить? не верю!

Может он аппаратно определить размер пакета и даже делает это неоднократно для каждого Ethernet пакета: логика/конечный автомат порта проверяет размер/CRC при приёме пакета из среды(L1), при выделении буферов под пакет на L2. Ответить аппаратно не может. Очень сложно для аппаратуры сформировать обмен на L3. Нужно процессор привлекать...

39 минут назад, boss-chifra сказал:

он уже может отвечать ICMP Frag needed and DF set (mtu = 1500) при пинге в не существующий IP (192.168.160.2 это HPE) а 192.168.160.2 не существующий IP

В этом случае (пингуем несуществующий IP) в аппаратуре происходит ошибка определения смежности (нужно заполнить поле DST MAC, а нечем). При этом происходит привлечение процессора, он формирует обмен по протоколу ARP для выяснения MACа получателя пакета и заполняет (или не заплняет) новую строчку в аппаратной таблице смежности. Дальнейшее взаимодействие осуществляет аппаратура.

Вот при привлечении процессора и появляется возможность включить более сложную _программную_ логику и проинформировать отправителя о его завышенных ожиданиях.