Переходим на L3, на радиосети из Микротиков.

[tcup]

@npokypop попробуй включить

 

Ограничь скорости при тесте до 100, либо 90 в обе стороны. Может, захлёбывается

[Saab95]

В 16.06.2025 в 04:26, npokypop сказал:

Почему сквозной трафик резется в два раза ?

Может, попробовать, указать MTU на всех бриджах в 1500 байт вручную?

[npokypop]

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

Может, попробовать, указать MTU на всех бриджах в 1500 байт вручную?

Смысл в чем ? Обоснуйте предложение.

[Saab95]

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

Смысл в чем ? Обоснуйте предложение.

Когда работало на L2 трафик проходил транзитом через бриджи и сам MTU бриджа не имел никакой роли для цели пропуска данных.

 

Когда переключили на L3, могла получится ситуация, что какие-то устройства стали работать с низким MTU, отсюда и падение скорости. И самая плохая ситуация может быть такого плана - что в одну сторону 1500 байт проходит, а по обратному каналу не проходит. Будут разные странности в работе интернета у абонентов.

[witch]

В 07.06.2025 в 10:19, npokypop сказал:

По рекомендации Сааба, решил, один луч сети из 3-х радиомостов, общей протяженностью около 23км, перевести с L2 транспорта на L3.

 

Ну есть же поговорка, Работает - не трогай. клиенты ещё не психуют или это не продакшн?

[npokypop]

В 21.06.2025 в 13:21, witch сказал:

Ну есть же поговорка, Работает - не трогай. клиенты ещё не психуют или это не продакшн?

Очень маленький сегмент сети перевел на L3 для теста, основная часть через этот же канал в L2 летит и так все хорошо.

[straus]

Обычно любые действия выполняются с какой-то целью. Что не устраивало при L2? Какая цель преследовалась переходом на L3?

[npokypop]

8 часов назад, straus сказал:

Обычно любые действия выполняются с какой-то целью. Что не устраивало при L2? Какая цель преследовалась переходом на L3?

Выше по теме отвечал на такой вопрос.

Цель : OSPF, ECMP

 

[straus]

Позволю себе быть нудным.

OSPF и ECMP - это средства достижения цели. А какова именно цель их использования? Что в существующей L2 сети не устраивает, что принято решение изменить её структуру? Прорабатывались ли другие способы решения проблем?

 

Это только у Saab95 аббревиатуры L3 и OSPF - самоцель. Ну в силу отсутствия знаний. Умные люди обычно стараются решить проблему наиболее оптимальным способом.

[npokypop]

1 час назад, straus сказал:

Позволю себе быть нудным.

OSPF и ECMP - это средства достижения цели. А какова именно цель их использования? Что в существующей L2 сети не устраивает, что принято решение изменить её структуру? Прорабатывались ли другие способы решения проблем?

 

Это только у Saab95 аббревиатуры L3 и OSPF - самоцель. Ну в силу отсутствия знаний. Умные люди обычно стараются решить проблему наиболее оптимальным способом.

Мне нравится ваш конструктивный подход к вопросу.

Попробую определить саму цель.

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

2. Увеличение емкости каналов, трафик из пункта A в пункт D, распределялся по нескольким каналам через B и C. Каналов и путей трафика может быть больше чем 2.

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

 

Это основные задачи.

[straus]

Понятно.

Для более глубокого понимания (мне) наверное нужно схему сети с адресацией и масками.

Но уже сразу скажу один момент, который выработался за годы опыта: если нет каких-либо специальных условий - всё резервирование и агрегирование каналов должно осуществляться на возможно более низком уровне.

 

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

Мне кажется, что здесь задачи именно для L2. И да, в случае локальной сети резервировать лучше на L2 ("прозрачно" для верхних уровней), всячески избегая необходимости перестроения маршрутизации.

 

Вспомнился ещё один момент. В некоторых оптических конвертерах ("медиках") есть одна интересная фича, которая помогает в таких случаях. К сожалению в радиомостах эта фича редкость. Смысл в том, что при падении оптического линка конвертер принудительно отключает свой медный порт. И таким образом "медные" устройства по краям оптического линка моментально видят падение оного, без необходимости всяких протоколов.

[sheft]

31 минуту назад, straus сказал:

Мне кажется, что здесь задачи именно для L2. И да, в случае локальной сети резервировать лучше на L2 ("прозрачно" для верхних уровней), всячески избегая необходимости перестроения маршрутизации

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

[Morty]

34 минуты назад, straus сказал:

Мне кажется, что здесь задачи именно для L2

Опишите, пожалуйста, как вы сделаете агрегирование двух радиолинков на уровне L2 с сохранением резервирования?

[straus]

39 минут назад, Morty сказал:

Опишите, пожалуйста, как вы сделаете агрегирование двух радиолинков на уровне L2 с сохранением резервирования?

Самый простой способ - использовать радиолинки, которые умеют сообщать о потере радиоканала. Тогда вместо самостоятельного определения целостности частей агрегации нам нужно только обеспечить реакцию на потерю.

 

48 минут назад, sheft сказал:

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

Да, согласен. Но радиолинк - это не обязательно Wi-Fi, у радиомостов ситуация заметно лучше.

И нужно учитывать моменты, которые могут облегчить решение задачи. Например, если для нашей ситуации допустимо использовать агрегацию без полноценной балансировки. То есть, распределять не весь агрегированный канал, а его составные части. К примеру, канал 4х100 мбит/с, но для каждого отдельного MAC-адреса не требуется более 1х100 мбит/с. В этом случае задача полноценной балансировки упрощается до задачи динамического распределения виртуальных каналов. Или даже до статического распределения, если вдруг допустимо.

 

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

[straus]

1 час назад, sheft сказал:

в беспроводке столько всего наворочено.. и агрегация пакетов и хуча всего что не дает нормально работать балансировщикам трафика на l2

Подумалось... А ведь на L3 полноценная балансировка в принципе невозможна. На нём понятие балансировки отличается от понятия балансировки на L2. Если на L2 можно распараллелить поток по всему транку (лучший случай, полноценный транк) или по виртуальным каналам и MAC-адресам (худший случай, виртуальные каналы), то L3 может только распределить нагрузку по каналам с учётом IP-адресов.

Выводы:

1. Даже худший вариант распределения потока на L2 ничем не хуже того же на L3.

2. Особенности работы с трафиком Wi-Fi создают для L3 ровно такие же проблемы, как и для L2.

[jffulcrum]

10 часов назад, straus сказал:

А ведь на L3 полноценная балансировка в принципе невозможна. На нём понятие балансировки отличается от понятия балансировки на L2. Если на L2 можно распараллелить поток по всему транку (лучший случай, полноценный транк) или по виртуальным каналам и MAC-адресам (худший случай, виртуальные каналы), то L3 может только распределить нагрузку по каналам с учётом IP-адресов.

натягивание пернатого на модель планеты ощущаю я...алгоритмы балансировки +/- одни и те же

[straus]

1 час назад, jffulcrum сказал:

натягивание пернатого на модель планеты ощущаю я...алгоритмы балансировки +/- одни и те же

Позволю себе возразить. Алгоритмы таки разные. Одно из принципиальных отличий (не касательно нашей обсуждаемой темы, тут сложнее) - на L3 каналы рассматриваются, как отдельные, с разными характеристиками; а в случае транка L2 - как части одного канала с полностью идентичными характеристиками. Пакеты, прошедшие транк L2, придут ровно в той же последовательности, и с задержкой ровно на время свитчинга (SaF). Пакеты, прошедшие балансинг L3, могут прийти с каналов в произвольном порядке. И понятие "пакет" в L2 и L3 тоже отличается. И ещё есть отличия, если копнуть глубоко.

Один из способов решения проблем с разнобоем пакетов - делать балансинг на основе Destination (MAC на L2 при каналах с ненормированной задержкой, или IP на L3). Тогда все пакеты к одному адресу назначения направляются через один и тот же канал. Но это не полноценный балансинг.

 

Ещё раз уточняю: это всё касается только чистого соединения агрегацией каналов между свитчами L2. Но в этой теме указаны радиоканалы, поэтому будет всё не так радужно.

[npokypop]

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

Позволю себе возразить. Алгоритмы таки разные. Одно из принципиальных отличий (не касательно нашей обсуждаемой темы, тут сложнее) - на L3 каналы рассматриваются, как отдельные, с разными характеристиками; а в случае транка L2 - как части одного канала с полностью идентичными характеристиками. Пакеты, прошедшие транк L2, придут ровно в той же последовательности, и с задержкой ровно на время свитчинга (SaF). Пакеты, прошедшие балансинг L3, могут прийти с каналов в произвольном порядке. И понятие "пакет" в L2 и L3 тоже отличается. И ещё есть отличия, если копнуть глубоко.

Один из способов решения проблем с разнобоем пакетов - делать балансинг на основе Destination (MAC на L2 при каналах с ненормированной задержкой, или IP на L3). Тогда все пакеты к одному адресу назначения направляются через один и тот же канал. Но это не полноценный балансинг.

 

Ещё раз уточняю: это всё касается только чистого соединения агрегацией каналов между свитчами L2. Но в этой теме указаны радиоканалы, поэтому будет всё не так радужно.

Вот почему от L2 балансировки отказались.

 

Пока удалось определить что канал Rx падает в двое при переходе потока с ether интерфейса на wlan интерфейс. Т.е сам процесс "перекладывания" пакетов (фреймов) рубит скорость в два раза примерно, как углубленно посмотреть что происходит на микртике пока не понял.

[sheft]

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

Пока удалось определить что канал Rx падает в двое при переходе потока с ether интерфейса на wlan интерфейс. Т.е сам процесс "перекладывания" пакетов (фреймов) рубит скорость в два раза примерно, как углубленно посмотреть что происходит на микртике пока не понял.

там не перекладывание, там "склейка" происходит, один радиокадр условно содержит несколько ethernet пакетов, и насколько помню он не 1400 а 4к в радио... но не точно, глубоко радио "палкой не тыкал" уже лет 6

[straus]

11 часов назад, npokypop сказал:

Т.е сам процесс "перекладывания" пакетов (фреймов) рубит скорость в два раза примерно

Ну так это фундаментальное отличие работы на втором и третьем уровнях. На втором уровне пакет может быть передан/направлен на интерфейс. На третьем уровне пакет должен быть обработан и изменён.

 

Я иногда задаю вопрос с подвохом "чем отличается коммутация L3 от маршрутизации?".  Вроде и то и то работает с третьим уровнем. Но есть принципиальное различие.

 

И при L3 надо ещё вспомнить про задержки на полный приём/подтверждение приёма/обработку/полную передачу/подтверждение передачи. На каждом хопе. А в случае радиоинтерфейса ещё и сборку радиокадра/полную передачу длинного радиокадра/проверку целостности/разборку.

И это мы ещё не дошли до балансировки L3 с динамическим контролем каналов. Тут будет вообще весело.

[npokypop]

Может кто находил информацию, как проходит L2 \ L3 трафик между wlan1 и ether1 интерфейсами в Mikrotik Router OS.

Прямого свитчинга между этими интерфейсами нет, а значит все идет через CPU в любом случаи. Понятно что L3 даст больше нагрузки на цпу, даст больше задержки при обработке, но это не главное сейчас. Надо выяснить где и почему происходит drop части пакетов (фреймов), думаю в этом причина уменьшения канала.

[straus]

На L2 идёт работа с сырым пакетом - нужно прочитать/записать кусок данных из одного драйвера в другой. При L3 идёт разборка пакета, отправка в стек, обработка с прогоном по таблицам, изменение заголовка пакета, опять отправка в стек... Загрузка процессора отличается более, чем в сотню раз.

[Saab95]

14 часов назад, npokypop сказал:

думаю в этом причина уменьшения канала.

Конфиг антенны и клиента уже выкладывали?

 

IP адреса верно установили? Ether1 имеет IP адрес для работы с кабельной сетью, беспроводной интерфейс wlan добавлен в bridge, и так же в бридж добавляется WDS интерфейс при подключении клиента?

 

MTU в этом случае что на кабельной сети, что в радио, совпадает?

[npokypop]

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

Конфиг антенны и клиента уже выкладывали?

 

IP адреса верно установили? Ether1 имеет IP адрес для работы с кабельной сетью, беспроводной интерфейс wlan добавлен в bridge, и так же в бридж добавляется WDS интерфейс при подключении клиента?

 

MTU в этом случае что на кабельной сети, что в радио, совпадает?

Не используем WDS, работаем в режиме bridge - station bridge

 

Объясните, зачем городить еще какие-то костыли в виде WDS ? 

[npokypop]

@Saab95Зачем wlan1 интерфейс добавлять в Bridge при роутинге трафика ?