Перейти к содержимому
Калькуляторы
9 hours ago, boss-chifra said:

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

Вы какой-то натурный эксперимент между офисами проводите, что вам jumbo нужны? Или есть какая-то практическая цель?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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/

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

просто разработчикам такой сценарий использования (использование l3 свитча между сегментами с разным mtu) не пришёл в голову.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 минуту назад, edo сказал:

топикстартер прав в том плане, что технически ничего невозможного тут нет.

Нет, технически невозможного действительно нет.

Но разговор тут скорее про порог целесообразности. Можно, можно предусмотреть в железе и такой хук. Пусть железо при необходимости дробления пакета дёргает процессор. А он уже или дробит или ICMP шлёт.

Но, вот незадача: Что же делать, если таких пакетов полетит пару сотен к в секунду?!? Не понадобится ли для обработки потока пара Xeon'ов? Или, что интереснее, SRC IP адрес будет поддельным? Кому тогда прилетит этот поток ICMP ответов?

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 прошивки не влезают на флешку, каждый раз при обновлении лотерея, вдруг новая прошивка не взлетит и все, старой уже нет, удалена что-бы было место для новой.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 часа назад, edo сказал:

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

просто разработчикам такой сценарий использования (использование l3 свитча между сегментами с разным mtu) не пришёл в голову.

 

 

Технически это как? Опишите реализацию так, чтобы она была не CPU зависима. 

 

Для обеспечения данного функционала на скорости порта там нужны не два ксенона, т.к ксеон все таки процессор общего назначения и не гарантирует опереденного показателя задержки. Тут потребуются специализированные NCPU с RISC  архитектурой. И такие ставят в роутеры. Просто не нужно выбирать l3 свитч, когда задача требует роутер. 

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

так как HPE не может отвечать "ICMP Frag needed" 

А может оказаться так, что отправитель не реагирует на это сообщение или вообще на нём ICMP зафильтрован? Кто тогда будет виноват?

Вы странным образом не хотите понимать то, как это работает _на самом деле_ и упорно настаиваете на своих фантазиях относительно устройства L3 коммутаторов. Вот действительно: Ну что бы ему стОило... А вот не может он так и точка.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

21 minutes ago, SokolovS said:
5 hours ago, edo said:

 

Технически это как? Опишите реализацию так, чтобы она была не CPU зависима

не знаю как там с зависимостью но он это делает для не существующих IP в сети

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

22 минуты назад, SokolovS сказал:

ксеон все таки процессор общего назначения и не гарантирует опереденного показателя задержки

Минуточку. Дело не в процессоре, а в ОС. Если не использовать ОС реального времени, а обычный линукс, то да, время ответа будет не детерминировано. Но, и для x86 есть ОСРВ... Как и для линукс есть патчи для поддержки мягкого РВ. Ну, или тот же Wind River со своим VxWorks

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

6 minutes ago, sol said:

Кто тогда будет виноват?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Я объяснил в чём разница. Если она кажется вам не сильно большой, что-ж. Дело ваше.

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

Просто я её позиционировал как Могущую а не аналог микротика.

Подобным образом будет вести себя _любой_ L3 _коммутатор_. А вот как раз микротик, который _маршрутизатор_ будет вести себя так, как вы ожидаете.

 

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

26 minutes ago, sol said:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

экзактли! а кажется что может быть проще, и главное они уже шлют "Frag needed" но только для PING пакетов больших а не UDP/TCP редиски, тоесть не докрутили немного функционал.

Едет крутой бизнесмен по городу. Вдруг звонит мобильный. Подносит трубку к уху - а там его начальник службы безопасности:
- Шеф, будьте поосторожнее! Мне сообщили, что в вашем районе какой-то козел по встречной полосе едет!
- Если б какой-то! Тут их сотни!

 

7 часов назад, sol сказал:

Но разговор тут скорее про порог целесообразности. Можно, можно предусмотреть в железе и такой хук. Пусть железо при необходимости дробления пакета дёргает процессор. А он уже или дробит или ICMP шлёт.

Но, вот незадача: Что же делать, если таких пакетов полетит пару сотен к в секунду?!? Не понадобится ли для обработки потока пара Xeon'ов?

решение этой проблемы давно придумано: rate-limit. 10 будут переданы процессору, остальные отброшены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

был бы запрос на такую конфигурацию — давно было бы во всех свитчах.

 

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

Просто я её позиционировал как Могущую

вот-вот, в технических вопросах негоже руководствоваться эмоциями.

 

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

не могу иметь vlan с разными MTU так как HPE не может отвечать

почему не можете? можете. просто маршрутизировать между ними нужно сторонней железкой (о чём вам давно сказали).

 

 

 

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

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

а зачем там зион? чтобы натужнее гудеть вентиляторами?

при разделении control plane и data plane особая мощь процессора и не нужна. а если не разделять — получим софтроутер, тоже имеет право на жизнь, но это уже совсем другая история.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

был бы запрос на такую конфигурацию — давно было бы во всех свитчах.

это не выгодно производителям

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

в третьих чипы делают в угоду определенным требованиям

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

а если всё же это всё реализовать то окажется что это роутер, а никакой уже не свич

 

2 часа назад, sol сказал:

Минуточку. Дело не в процессоре

а в чипе и в том какая часть траффика вообще может попасть на цпу

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

9 hours ago, boss-chifra said:

я нет, но итог этой дискусии идет к тому что даже и в одном офисе не могу иметь vlan с разными MTU так как HPE не может отвечать "ICMP Frag needed"  и JUMBO могуть жить только в изолированных сегментах или сегментах что маршрутизируются через честный L3 маршрутизатор.

Почему же? Вполне можете. Тот интерфейс (SVI), на котором у вас jumbo отключены, вполне отвечает "ICMP Frag needed" и пакеты пришедшие с интерфейса с jumbo будут фрагментироваться в него. Правда и здесь есть нюансы.

Но вы же хотите большего - не дефрагментировать пакеты проходящие через интерфейс с поддержкой jumbo.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

19 часов назад, sol сказал:

Минуточку. Дело не в процессоре, а в ОС. Если не использовать ОС реального времени, а обычный линукс, то да, время ответа будет не детерминировано. Но, и для x86 есть ОСРВ... Как и для линукс есть патчи для поддержки мягкого РВ. Ну, или тот же Wind River со своим VxWorks

 

 

Да, все так. Но это уже будет не свитч, а роутер :) Каждая реализация хороша для своих задач.

 

19 часов назад, boss-chifra сказал:

не знаю как там с зависимостью но он это делает для не существующих IP в сети

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

 

Да конечно нет разницы, только вы одно поймите, что в случае с данной железкой это с вероятностью 99.9% CPU зависимая операция. В свичи как правило ставят процессоры достаточно слабые и определенный объем ICMP, который может случиться просто из-за ошибки конфигурирования или из-за состояния сетевой среды, просто сожрет все его время. А в спектр задач свича входят пересылка трафика на скорости порта, это его специализация, в этом его преимущество и под это заточено все железо.

Изменено пользователем SokolovS

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Профит от использования jumbo больше чем проблемы от потерь udp между сегментами?

Юзкейс можете всё-таки озвучить?

Я знаю только одну причину использования mtu>1500 - вам надо оверлей поверх сети запустить и обычно речь идёт об л2 при этом.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Обычно wi-fi точки и их контроллеры умеют поднимать VPN между собой и передавать данные внутри этого туннеля, при этом на размеры МТУ им побоку. Может посмотреть в этом направлении.

И да, представьте себе провайдеров, которые гоняют большие объемы абонентского трафика через свои 10-40-100г каналы с мту 1500 и как-то нормально себя чувствуют.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

@Saab95

Любезнейший, прокомментируйте лучше возможность включить jumbo на гигабитных интерфейсах микротика. Пользы больше будет.

 

 

3 часа назад, Saab95 сказал:

И да, представьте себе провайдеров, которые гоняют большие объемы абонентского трафика через свои 10-40-100г каналы с мту 1500 и как-то нормально себя чувствуют.

SAN/NAS, iSCSI, FCoE? Не, не слышал... Да и технологии устаревшие, правда?

Вообще то, для чего т.с. нужны jumbo вопрос десятый. Нужны значит для чего-то. Вопрос топика был не в том, как обойтись без этого, а в том, что к существующей сети "с" надо привязать сегмент "без". И только.

Может, т.с. там распределённый кластер ceph гоняет/реплицирует.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 :-(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

20 часов назад, Saab95 сказал:

И да, представьте себе провайдеров, которые гоняют большие объемы абонентского трафика через свои 10-40-100г каналы с мту 1500 и как-то нормально себя чувствуют.

К сожалению нам с этим говном ещё долго жить, как и с IPv4.

 

Джамбо позволяет сократить накладные расходы на передачу служебных заголовков тем самым экономя полосу, так же он сокращает нагрузку на всё промежуточное оборудование потому что пакетрейт кратно падает, ибо один джамбо фрейм заменяет собой как минимум 4 обычных, те нагрузка в пакетах легко уменьшается минимум в 4 раза, то и 8+ раз.

Это всё особенно актуально для всяких софтовых штук: софтроутеров и серверов. Конечно там производители постарались с оффлоадингами, и для тех же рабочих станций и серверов интеловые++ сетевухи сами делаюи так, как будто джабо пришло или можно сразу джамбу отослать, а сетевуха сама соберёт/разберёт его, но с роутингом и некоторыми другими задачами это не проканывает.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ну, когда в далёком 1973 году маленький Боб Меткалф писАл свою докладную записку буграм из Xerox, то он не думал о том, что всего-то через ~50 лет будут распространены интерфейсы в 100G и коэффициент ошибок в линиях связи опустится ниже 10^-12.

 

Он думал как Уильям Гейтс II, что 720 килобайт хватит всем...

 

Вот и выбрал мало того, что небольшой пакет, чтобы вероятность возникновения в пакете ошибки была мала, так ещё и переменный размер пакета...

 

Прошло пол века... Вероятность ошибок снизилась, 720к стало мало и размер RAM стал мерятся гигабайтами...

Пора уже переходить к пакетам побольше.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 05.01.2021 в 00:19, sol сказал:

Любезнейший, прокомментируйте лучше возможность включить jumbo на гигабитных интерфейсах микротика. Пользы больше будет.

Если бы роутинг был не на коммутаторах, или точки доступа с контроллером были от микротика - можно было бы легко решить задачу, а так она не решаема.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.