dr Tr0jan Опубликовано 29 декабря, 2020 · Жалоба 9 hours ago, boss-chifra said: по заверениям разрабов малина 4 на сетевой имеет предел в pps и что-бы её разкачать нужно пакетики по больше слать и не упираться в pps (малина нужна как доступный arm64) Вы какой-то натурный эксперимент между офисами проводите, что вам jumbo нужны? Или есть какая-то практическая цель? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 30 декабря, 2020 · Жалоба 14 часов назад, 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 (172.30.160.1) 1600(1628) bytes of data. From 192.168.160.2 icmp_seq=1 Frag needed and DF set (mtu = 1500) Вы понимаете, что OSPF и BGP не участвуют в передаче данных, они работают исключительно с таблицами в памяти коммутатора и для работы используют CPU? Много CPU они вряд ли заберут, т.к. трафик как правило небольшой. А вот порты должны работать вплоть до максимальной скорости и без увеличения задержек и если на каждый пакет будет генериться ICMP (с использованием CPU конечно же, по другому никак), то смерть CPU, загрузка будет в полку! На L3 коммутаторах вообще такая возможность скорее зло, т.к. позволяет его положить за пару минут. Почитайте, вот простой материальчик:https://habr.com/ru/company/cbs/blog/301000/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 30 декабря, 2020 · Жалоба мне кажется, вы все неправильно объясняете. топикстартер прав в том плане, что технически ничего невозможного тут нет. просто разработчикам такой сценарий использования (использование l3 свитча между сегментами с разным mtu) не пришёл в голову. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 30 декабря, 2020 · Жалоба 1 минуту назад, edo сказал: топикстартер прав в том плане, что технически ничего невозможного тут нет. Нет, технически невозможного действительно нет. Но разговор тут скорее про порог целесообразности. Можно, можно предусмотреть в железе и такой хук. Пусть железо при необходимости дробления пакета дёргает процессор. А он уже или дробит или ICMP шлёт. Но, вот незадача: Что же делать, если таких пакетов полетит пару сотен к в секунду?!? Не понадобится ли для обработки потока пара Xeon'ов? Или, что интереснее, SRC IP адрес будет поддельным? Кому тогда прилетит этот поток ICMP ответов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boss-chifra Опубликовано 30 декабря, 2020 · Жалоба 15 hours ago, dr Tr0jan said: Вы какой-то натурный эксперимент между офисами проводите, что вам jumbo нужны? Или есть какая-то практическая цель? я нет, но итог этой дискусии идет к тому что даже и в одном офисе не могу иметь vlan с разными MTU так как HPE не может отвечать "ICMP Frag needed" и JUMBO могуть жить только в изолированных сегментах или сегментах что маршрутизируются через честный L3 маршрутизатор. 8 hours ago, SokolovS said: Почитайте, вот простой материальчик:https://habr.com/ru/company/cbs/blog/301000/ спасибо почитаю 8 hours ago, SokolovS said: На L3 коммутаторах вообще такая возможность скорее зло, т.к. позволяет его положить за пару минут. да тут я скорее соглашусь но это все грустно что эти дорогущие железки заявляют поддержку JUMBO но в реальности она урезанная и для маршрутизируемого трафика её нет 4 hours ago, edo said: (использование l3 свитча между сегментами с разным mtu) не пришёл в голову. экзактли! а кажется что может быть проще, и главное они уже шлют "Frag needed" но только для PING пакетов больших а не UDP/TCP редиски, тоесть не докрутили немного функционал. 4 hours ago, sol said: Не понадобится ли для обработки потока пара Xeon'ов? я удивлен что их там еще нет за эти тысячи долларов цены. Даже иногда флешки ставять такие маленькие что 2 прошивки не влезают на флешку, каждый раз при обновлении лотерея, вдруг новая прошивка не взлетит и все, старой уже нет, удалена что-бы было место для новой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 30 декабря, 2020 (изменено) · Жалоба 4 часа назад, edo сказал: мне кажется, вы все неправильно объясняете. топикстартер прав в том плане, что технически ничего невозможного тут нет. просто разработчикам такой сценарий использования (использование l3 свитча между сегментами с разным mtu) не пришёл в голову. Технически это как? Опишите реализацию так, чтобы она была не CPU зависима. Для обеспечения данного функционала на скорости порта там нужны не два ксенона, т.к ксеон все таки процессор общего назначения и не гарантирует опереденного показателя задержки. Тут потребуются специализированные NCPU с RISC архитектурой. И такие ставят в роутеры. Просто не нужно выбирать l3 свитч, когда задача требует роутер. Изменено 30 декабря, 2020 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 30 декабря, 2020 · Жалоба 57 минут назад, boss-chifra сказал: так как HPE не может отвечать "ICMP Frag needed" А может оказаться так, что отправитель не реагирует на это сообщение или вообще на нём ICMP зафильтрован? Кто тогда будет виноват? Вы странным образом не хотите понимать то, как это работает _на самом деле_ и упорно настаиваете на своих фантазиях относительно устройства L3 коммутаторов. Вот действительно: Ну что бы ему стОило... А вот не может он так и точка. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boss-chifra Опубликовано 30 декабря, 2020 · Жалоба 21 minutes ago, SokolovS said: 5 hours ago, edo said: Технически это как? Опишите реализацию так, чтобы она была не CPU зависима не знаю как там с зависимостью но он это делает для не существующих IP в сети пример я показывал тут Тоесть он уже это делает но только для не существующих IP и жаль что тоже самое не может для существующих сделать, мне не кажется что сильно большая разница. Но если подходить с колокольни клиент сам дурак и хочет слишком много от такой простой железки то вы правы. Просто я её позиционировал как Могущую а не аналог микротика. Я согласен лишь в том что да мы сами виноваты в выборе такого барахла, но в момент выбора это не предусмотрели, факт. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 30 декабря, 2020 · Жалоба 22 минуты назад, SokolovS сказал: ксеон все таки процессор общего назначения и не гарантирует опереденного показателя задержки Минуточку. Дело не в процессоре, а в ОС. Если не использовать ОС реального времени, а обычный линукс, то да, время ответа будет не детерминировано. Но, и для x86 есть ОСРВ... Как и для линукс есть патчи для поддержки мягкого РВ. Ну, или тот же Wind River со своим VxWorks Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boss-chifra Опубликовано 30 декабря, 2020 · Жалоба 6 minutes ago, sol said: Кто тогда будет виноват? виноват тот кто зафильтровал ICMP и сломал механизм PMTU Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 30 декабря, 2020 · Жалоба 35 минут назад, boss-chifra сказал: только для не существующих IP и жаль что тоже самое не может для существующих сделать, мне не кажется что сильно большая разница Я объяснил в чём разница. Если она кажется вам не сильно большой, что-ж. Дело ваше. 36 минут назад, boss-chifra сказал: Просто я её позиционировал как Могущую а не аналог микротика. Подобным образом будет вести себя _любой_ L3 _коммутатор_. А вот как раз микротик, который _маршрутизатор_ будет вести себя так, как вы ожидаете. В целом, вы можете отбросить то, что вы себе нафантазировали относительно механизмов работы L3 коммутаторов и послушать то, что вам тут говорят несколько человек. А можете этого и не делать. Выбор за вами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boss-chifra Опубликовано 30 декабря, 2020 · Жалоба 26 minutes ago, sol said: В целом, вы можете отбросить то, что вы себе нафантазировали относительно механизмов работы L3 коммутаторов и послушать то, что вам тут говорят несколько человек. А можете этого и не делать. Выбор за вами. тут с вами полностью согласен Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 30 декабря, 2020 · Жалоба 3 часа назад, boss-chifra сказал: экзактли! а кажется что может быть проще, и главное они уже шлют "Frag needed" но только для PING пакетов больших а не UDP/TCP редиски, тоесть не докрутили немного функционал. Едет крутой бизнесмен по городу. Вдруг звонит мобильный. Подносит трубку к уху - а там его начальник службы безопасности: - Шеф, будьте поосторожнее! Мне сообщили, что в вашем районе какой-то козел по встречной полосе едет! - Если б какой-то! Тут их сотни! 7 часов назад, sol сказал: Но разговор тут скорее про порог целесообразности. Можно, можно предусмотреть в железе и такой хук. Пусть железо при необходимости дробления пакета дёргает процессор. А он уже или дробит или ICMP шлёт. Но, вот незадача: Что же делать, если таких пакетов полетит пару сотен к в секунду?!? Не понадобится ли для обработки потока пара Xeon'ов? решение этой проблемы давно придумано: rate-limit. 10 будут переданы процессору, остальные отброшены. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
edo Опубликовано 30 декабря, 2020 · Жалоба был бы запрос на такую конфигурацию — давно было бы во всех свитчах. 2 часа назад, boss-chifra сказал: Просто я её позиционировал как Могущую вот-вот, в технических вопросах негоже руководствоваться эмоциями. 3 часа назад, boss-chifra сказал: не могу иметь vlan с разными MTU так как HPE не может отвечать почему не можете? можете. просто маршрутизировать между ними нужно сторонней железкой (о чём вам давно сказали). 3 часа назад, boss-chifra сказал: я удивлен что их там еще нет за эти тысячи долларов цены. Даже иногда флешки ставять такие маленькие что 2 прошивки не влезают на флешку, каждый раз при обновлении лотерея, вдруг новая прошивка не взлетит и все, старой уже нет, удалена что-бы было место для новой. а зачем там зион? чтобы натужнее гудеть вентиляторами? при разделении control plane и data plane особая мощь процессора и не нужна. а если не разделять — получим софтроутер, тоже имеет право на жизнь, но это уже совсем другая история. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 30 декабря, 2020 · Жалоба 13 минут назад, edo сказал: был бы запрос на такую конфигурацию — давно было бы во всех свитчах. это не выгодно производителям во первых надо роутеры продавать, во вторых цена свича который сможет в фрагментацию пакетов будет сильно дороже в третьих чипы делают в угоду определенным требованиям свич просто быстро отбросит пакет чем будет ждать пока цпу решит чо с пакетом делать, буфер знаете ли а если всё же это всё реализовать то окажется что это роутер, а никакой уже не свич 2 часа назад, sol сказал: Минуточку. Дело не в процессоре а в чипе и в том какая часть траффика вообще может попасть на цпу копировать каждый пакет который дропнулся для анализа на цпу на тему того "а почему же? а может послать icmp ответ?" ясное дело что быть беде либо расширять возможности чипа но опять же цена и общее положение рынка Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
dr Tr0jan Опубликовано 31 декабря, 2020 · Жалоба 9 hours ago, boss-chifra said: я нет, но итог этой дискусии идет к тому что даже и в одном офисе не могу иметь vlan с разными MTU так как HPE не может отвечать "ICMP Frag needed" и JUMBO могуть жить только в изолированных сегментах или сегментах что маршрутизируются через честный L3 маршрутизатор. Почему же? Вполне можете. Тот интерфейс (SVI), на котором у вас jumbo отключены, вполне отвечает "ICMP Frag needed" и пакеты пришедшие с интерфейса с jumbo будут фрагментироваться в него. Правда и здесь есть нюансы. Но вы же хотите большего - не дефрагментировать пакеты проходящие через интерфейс с поддержкой jumbo. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SokolovS Опубликовано 31 декабря, 2020 (изменено) · Жалоба 19 часов назад, sol сказал: Минуточку. Дело не в процессоре, а в ОС. Если не использовать ОС реального времени, а обычный линукс, то да, время ответа будет не детерминировано. Но, и для x86 есть ОСРВ... Как и для линукс есть патчи для поддержки мягкого РВ. Ну, или тот же Wind River со своим VxWorks Да, все так. Но это уже будет не свитч, а роутер :) Каждая реализация хороша для своих задач. 19 часов назад, boss-chifra сказал: не знаю как там с зависимостью но он это делает для не существующих IP в сети пример я показывал тут Тоесть он уже это делает но только для не существующих IP и жаль что тоже самое не может для существующих сделать, мне не кажется что сильно большая разница. Но если подходить с колокольни клиент сам дурак и хочет слишком много от такой простой железки то вы правы. Просто я её позиционировал как Могущую а не аналог микротика. Я согласен лишь в том что да мы сами виноваты в выборе такого барахла, но в момент выбора это не предусмотрели, факт. Да конечно нет разницы, только вы одно поймите, что в случае с данной железкой это с вероятностью 99.9% CPU зависимая операция. В свичи как правило ставят процессоры достаточно слабые и определенный объем ICMP, который может случиться просто из-за ошибки конфигурирования или из-за состояния сетевой среды, просто сожрет все его время. А в спектр задач свича входят пересылка трафика на скорости порта, это его специализация, в этом его преимущество и под это заточено все железо. Изменено 31 декабря, 2020 пользователем SokolovS Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vurd Опубликовано 1 января, 2021 · Жалоба Профит от использования jumbo больше чем проблемы от потерь udp между сегментами? Юзкейс можете всё-таки озвучить? Я знаю только одну причину использования mtu>1500 - вам надо оверлей поверх сети запустить и обычно речь идёт об л2 при этом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 4 января, 2021 · Жалоба Обычно wi-fi точки и их контроллеры умеют поднимать VPN между собой и передавать данные внутри этого туннеля, при этом на размеры МТУ им побоку. Может посмотреть в этом направлении. И да, представьте себе провайдеров, которые гоняют большие объемы абонентского трафика через свои 10-40-100г каналы с мту 1500 и как-то нормально себя чувствуют. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 4 января, 2021 · Жалоба @Saab95 Любезнейший, прокомментируйте лучше возможность включить jumbo на гигабитных интерфейсах микротика. Пользы больше будет. 3 часа назад, Saab95 сказал: И да, представьте себе провайдеров, которые гоняют большие объемы абонентского трафика через свои 10-40-100г каналы с мту 1500 и как-то нормально себя чувствуют. SAN/NAS, iSCSI, FCoE? Не, не слышал... Да и технологии устаревшие, правда? Вообще то, для чего т.с. нужны jumbo вопрос десятый. Нужны значит для чего-то. Вопрос топика был не в том, как обойтись без этого, а в том, что к существующей сети "с" надо привязать сегмент "без". И только. Может, т.с. там распределённый кластер ceph гоняет/реплицирует. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
boss-chifra Опубликовано 4 января, 2021 · Жалоба On 1/1/2021 at 8:58 AM, vurd said: Профит от использования jumbo больше чем проблемы от потерь udp между сегментами? Юзкейс можете всё-таки озвучить? я выше писал, у Raspberry есть ограничение на PPS, но повторюсь лично не проверял, со слов девелоперов поднятие MTU им помогло. 3 hours ago, Saab95 said: Обычно wi-fi точки и их контроллеры умеют поднимать VPN между собой да верно говорите, но я изначально я искал более общее решение, и тут меня убедили что я хочу странного. 6 minutes ago, sol said: возможность включить jumbo на гигабитных интерфейсах микротика а что тут коментировать? это возможно, но как я выяснил еще летом Микрот не умеет делать роуты с установкой MTU :-( Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 января, 2021 · Жалоба 20 часов назад, Saab95 сказал: И да, представьте себе провайдеров, которые гоняют большие объемы абонентского трафика через свои 10-40-100г каналы с мту 1500 и как-то нормально себя чувствуют. К сожалению нам с этим говном ещё долго жить, как и с IPv4. Джамбо позволяет сократить накладные расходы на передачу служебных заголовков тем самым экономя полосу, так же он сокращает нагрузку на всё промежуточное оборудование потому что пакетрейт кратно падает, ибо один джамбо фрейм заменяет собой как минимум 4 обычных, те нагрузка в пакетах легко уменьшается минимум в 4 раза, то и 8+ раз. Это всё особенно актуально для всяких софтовых штук: софтроутеров и серверов. Конечно там производители постарались с оффлоадингами, и для тех же рабочих станций и серверов интеловые++ сетевухи сами делаюи так, как будто джабо пришло или можно сразу джамбу отослать, а сетевуха сама соберёт/разберёт его, но с роутингом и некоторыми другими задачами это не проканывает. Удивительно что ты тут топишь против джамбы, уж твои то микротики от него бы сильно выиграли, они больше всех других в этом заинтересованы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sol Опубликовано 5 января, 2021 · Жалоба Ну, когда в далёком 1973 году маленький Боб Меткалф писАл свою докладную записку буграм из Xerox, то он не думал о том, что всего-то через ~50 лет будут распространены интерфейсы в 100G и коэффициент ошибок в линиях связи опустится ниже 10^-12. Он думал как Уильям Гейтс II, что 720 килобайт хватит всем... Вот и выбрал мало того, что небольшой пакет, чтобы вероятность возникновения в пакете ошибки была мала, так ещё и переменный размер пакета... Прошло пол века... Вероятность ошибок снизилась, 720к стало мало и размер RAM стал мерятся гигабайтами... Пора уже переходить к пакетам побольше. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Saab95 Опубликовано 6 января, 2021 · Жалоба В 05.01.2021 в 00:19, sol сказал: Любезнейший, прокомментируйте лучше возможность включить jumbo на гигабитных интерфейсах микротика. Пользы больше будет. Если бы роутинг был не на коммутаторах, или точки доступа с контроллером были от микротика - можно было бы легко решить задачу, а так она не решаема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...