boss-chifra

я выше писал, у Raspberry есть ограничение на PPS, но повторюсь лично не проверял, со слов девелоперов поднятие MTU им помогло. да верно говорите, но я изначально я искал более общее решение, и тут меня убедили что я хочу странного. а что тут коментировать? это возможно, но как я выяснил еще летом Микрот не умеет делать роуты с установкой MTU :-(

тут с вами полностью согласен

виноват тот кто зафильтровал ICMP и сломал механизм PMTU

Технически это как? Опишите реализацию так, чтобы она была не CPU зависима не знаю как там с зависимостью но он это делает для не существующих IP в сети пример я показывал тут Тоесть он уже это делает но только для не существующих IP и жаль что тоже самое не может для существующих сделать, мне не кажется что сильно большая разница. Но если подходить с колокольни клиент сам дурак и хочет слишком много от такой простой железки то вы правы. Просто я её позиционировал как Могущую а не аналог микротика. Я согласен лишь в том что да мы сами виноваты в выборе такого барахла, но в момент выбора это не предусмотрели, факт.

я нет, но итог этой дискусии идет к тому что даже и в одном офисе не могу иметь vlan с разными MTU так как HPE не может отвечать "ICMP Frag needed" и JUMBO могуть жить только в изолированных сегментах или сегментах что маршрутизируются через честный L3 маршрутизатор. спасибо почитаю да тут я скорее соглашусь но это все грустно что эти дорогущие железки заявляют поддержку JUMBO но в реальности она урезанная и для маршрутизируемого трафика её нет экзактли! а кажется что может быть проще, и главное они уже шлют "Frag needed" но только для PING пакетов больших а не UDP/TCP редиски, тоесть не докрутили немного функционал. я удивлен что их там еще нет за эти тысячи долларов цены. Даже иногда флешки ставять такие маленькие что 2 прошивки не влезают на флешку, каждый раз при обновлении лотерея, вдруг новая прошивка не взлетит и все, старой уже нет, удалена что-бы было место для новой.

Тоесть вы хотите сказать что он может все, от 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)

А вы точно меня слышите? я не прошу никакие >"аппаратно разбивать большие пакеты на маленькие" Я прошу простого принять пакет что он и так делает и ответить отправителю ICMP need to frag (mtu 1500) что скажет что пакет не проолазит в vlan так как там нельзя большие пакеты. он 100% принимает пакет как L3 так как он его будет маршрутизировать в другую сеть и он знает размер пакета и он мог-бы ответить отправителю ICMP как он это делает при обращении к несуществующим IP

на участке HPE-Linux роутер да разрешены Jumbo что-бы между офисам работал Jumbo и не вижу никаких проблем, да там могут быть или фрагментированные пакеты или полные Jumbo и тоже не понимаю чем это плохо. А проблема в том что HPE приняв Jumbo не может понять что vlan назначения не поддерживает Jumbo и нужно ответить отправителю ICMP (need to frag (mtu 1500)) по заверениям разрабов малина 4 на сетевой имеет предел в pps и что-бы её разкачать нужно пакетики по больше слать и не упираться в pps (малина нужна как доступный arm64) цена у него не балуй и 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 фич ну микротик я как раз люблю за идеальное решение цена качество, и все минусы ему прощаю за цену

а можно узнать в чем проблема со свеном 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)) ??? рыдаю

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

да вы правы идею поднятия vlan с установленным в нужное значение на Linux роутере я не думал но похоже это может решить проблему, кривовато но решение.   > моё ИМХО: роутинг в свитчах в большинстве случаев вовсе не нужен. ну когда у нас сотня vlan то не правильно работоспособность и связность сегментов зачем-то завязывать на Linux роутер. Стек свичей надежнее и по скорости быстрее, поэтому ядро сети сделано HPE. > --clamp-mss-to-pmtu это всего лишь работа с MSS у TCP а проблема с UDP

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

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

Есть железка которая шлет фрагментированные UDP пакеты, на железке MTU 1500, больше она не может. Когда ей нужно передать блок данных на 2500 байт она шлет этот один блок данных в 2 пакетах, тоесть как бы пакет один но из 2 сегменртов на 1500 и 1000 байт. Сеть у нас большая и на конечном отрезке пути маршрутизатор имеет MTU 9000 на обоих сторонах(да нам это нужно, почему нет?). Это приводит к тому что конечный маршрутизатор Linux принимает эти 2 сегмента и так как у него MTU 9000 он уже отправляет далее один пакет на 2500 байт. К сожалению принимающая железка не может принять пакет так как у нее 1500 MTU. (black hole hello) Вопрос, есть какие-то варианты запретить маршрутизатору Linux собирать пакет из сегментов? Кто-то вообще встречался с такой проблемой что какой-то софт шлет фрагментированные пакеты которые могут собраться где то в сети хотя сам этот софт не умеет принимать такие собранные пакеты (у нас это проблема с Wi-Fi точками и их контроллером управления)

Никто не использует H3C/3COM/HP ???