Перейти до

PTP550 Cambium Networks для 5 Ггц каналов точка -точка


Рекомендованные сообщения

Если qinq то весь трафик идет под одним маком

Есть предложения как его разделить? У меня пока нет идей

Ссылка на сообщение
Поделиться на других сайтах
  • Відповіді 670
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Славка, твой выход, трафик не такой, полнолуние, фаташоп, ну или чо там еще, мАлтипоинт, лос энлос, лосось, карась 

Классический пример вашей неадекватности восприятия результатов       Это у вас не тянули 5 лет, а когда показывали пример - глаза закрывали и всякие отговорки придумывали, что это не

А мимозу пробовали? Пока у нас это god-like вариант в любых условиях.

Posted Images

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

Если qinq то весь трафик идет под одним маком

:blink:

Кто сказал? Палковник?

2020-11-11_08-27-02.thumb.png.7f9e74f9cce6d9de77d0eed0414d0494.png

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
8 минут назад, Dimkers сказал:

:blink:

Кто сказал?

Да, не уточнил. Классический qinq нет, там просто 2 метки в пакете и всё. А туннелирование подразумевает один мак.

У меня много где было просто туннелирование и была та же проблема

Ссылка на сообщение
Поделиться на других сайтах
3 часа назад, Kiano сказал:

Классический qinq нет, там просто 2 метки в пакете и всё.

А в не классическом? 3 метки и тоже все? Ну и да, тут тоже 2 метки.

 

Ok, пойдем другим путем. Почему с одной стороны свич видит маки в QinQ пакете и нормально балансит трафик в свой аплинк в LAG, а камбиум, который включен в этот же свич - не хочет? :)

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
24 минуты назад, Dimkers сказал:

Ok, пойдем другим путем. Почему с одной стороны свич видит маки в QinQ пакете и нормально балансит трафик в свой аплинк в LAG, а камбиум, который включен в этот же свич - не хочет? :)

У них разная реализация балансировки, более того у свича она  поддерживается аппаратно.  Балансировка QinQ  вообще то у Камбиум  происходит, но что то  долго думает,  и как то неравномерно балансирует ( там кроме QinQ есть еще небольшой  трафик и возможно  он уводится во второй канал), видимо работает по обновлению bridge table или ARP Table. Вопрос с балансировкой QinQ изучаем.

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
39 минут назад, Dimkers сказал:

Ok, пойдем другим путем. Почему с одной стороны свич видит маки в QinQ пакете и нормально балансит трафик в свой аплинк в LAG, а камбиум, который включен в этот же свич - не хочет? :)

Ну тут уже хз, в мозги камбале не посмотрю

Ссылка на сообщение
Поделиться на других сайтах
34 минуты назад, Alver сказал:

более того у свича она  поддерживается аппаратно.

Да? И каким же чипом это реализуется в дешовеньком свиче типа Dlink DGS-1210?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
37 минут назад, Dimkers сказал:

Да? И каким же чипом это реализуется в дешовеньком свиче типа Dlink DGS-1210?

У  свичей доступа есть коммутационная матрица. Что там есть  у  длинка -х.з.

У PTP550 точно нет такой матрицы , она ему и не нужна.

У  свичей Камбиум матрица есть.

И получен ответ от Камбиум. Особенностей балансировки QinQ нет.  Почему медленно и неравномерно балансируется трафик у человека- разщберемся.

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

И как коммутационная матрица связана с хардварным LACP?

250px-Villi-vonka-nastalo-vremya.jpeg

Я тебя за язык не тянул. ты сам пизданул :)

Відредаговано Dimkers
  • Haha 1
Ссылка на сообщение
Поделиться на других сайтах
3 минуты назад, Alver сказал:

LACP -это агрегация на IP уровне

ГЫ. А как же тогда она балансится по src\dst MAC?

 

Спрыгнул :)

Ну ты это, понял, что херню пизданул про хардварный ЛАСП и коммутационную матрицу? И своим там передай, пусть книжки читают.

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
9 минут назад, Dimkers сказал:

про хардварный ЛАСП

Я про LACP ни про LAG ничего не говорил.   А коммутационная матрица в приличных свичах есть . Ты с этим спорить собираешься , что ли? И вообще мне  как реализован LACP  не интересно. Он в радиоканалах должным образом НЕ работает.  Закончим этот бестолковый офтоп.

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
8 минут назад, Alver сказал:

Я про LACP ни про LAG ничего не говорил.

 

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

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

 

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

Почему с одной стороны свич видит маки в QinQ пакете и нормально балансит трафик в свой аплинк в LAG, а камбиум, который включен в этот же свич - не хочет?

 

Я слушаю далее сказки венского леса.

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

А при чем тут коммутация пакетов в матрице, которая зачастую вообще проходит по номеру порта, к балансировке в LAG\LACP? :)

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
1 минуту назад, Dimkers сказал:

LAG\LACP?

Ни причем. Просто балансировка трафика  у Камбиум PTP550 и у свичей  LACP  разная. У Камбиум аппаратно-программная, у свичей коммутация аппаратная, агрегация -программная. Но дело не в этом, у них разные механизмы. 

Ссылка на сообщение
Поделиться на других сайтах
5 минут назад, Alver сказал:

Но дело не в этом

Дело в том, что в предмете вы поплыли.

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

5 минут назад, Alver сказал:

У Камбиум аппаратно-программная, у свичей коммутация аппаратная, агрегация -программная.

Ржу Бл#. Ты хотя сам понял шо написал?

5 минут назад, Alver сказал:

у них разные механизмы. 

У них разные рукажопы код пишут. да? В блялинке осилили, а в камбиуме - ну не шмогла....

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
21 минуту назад, Dimkers сказал:

Дело в том, что в предмете вы поплыли.

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

Ржу Бл#. Ты хотя сам понял шо написал?

У них разные рукажопы код пишут. да? В блялинке осилили, а в камбиуме - ну не шмогла....

 

У них задача вообще разная. Камбиум PTP550  трафик делит между каналами, а свичи - наоборот объединяют каналы.

Свичи Камбиум нормально  делают агрегацию LACP.

В радио PTP550 задача обратная- разделить трафик по меткам между каналами.

ЗЫ

Программисты длинк ничего в LACP   не делают. Бинарный код LACP и др. входит в SDK свича.

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

Ты дебил? Объясню на пальцах.

 

порт 10G свич - (порт LACP из 2*1G<->порт LACP из 2*1G) - порт 10G свич

Свич порт 1G - камбиум порт 1G <-> (камбиум 2 радиоканала WiFI) <-> камбиум порт 1G - свич порт 1G

 

9 минут назад, Alver сказал:

Программисты длинк ничего в LACP   не делают. Бинарный код LACP и др. входит в SDK свича.

А что делают програмисты камбиум?

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

Я правильно понял что PTP550 балансит трафик основываясь на маках, тогда ни по барабану ли в каких вланах эти маки.
Или тут свой какой-то уникальный алгоритм разделения ?

Ссылка на сообщение
Поделиться на других сайтах
Опубліковано: (відредаговано)
47 минут назад, mdbo сказал:

Я правильно понял что PTP550 балансит трафик основываясь на маках, тогда ни по барабану ли в каких вланах эти маки.
Или тут свой какой-то уникальный алгоритм разделения ? 

Деление  не по MAC . Если я где то ранее говорил про MAC, то это было  в ранних версиях, сейчас этого нет.

  И там точно уникальный алгоритм  именно разделения трафика  по 2-м  каналам  Load balancing , а не агрегации 2-х каналов в один .

Метки разделения

Transport layer of OSI model protocol type: TCP/UDP;

IP packets source address and TCP/UDP port: Source IP & Source TCP/UDP Port;

IP packets receive address and TCP/UDP port: Receive IP & Receive Port TCP/UDP Port;

Відредаговано Alver
Ссылка на сообщение
Поделиться на других сайтах
5 часов назад, Alver сказал:

И там точно уникальный алгоритм  именно разделения трафика  по 2-м  каналам  Load balancing , а не агрегации 2-х каналов в один .

Да? И какой же он уникальный???

5 часов назад, Alver сказал:

Если я где то ранее говорил про MAC, то это было  в ранних версиях, сейчас этого нет.

Так это было пару дней назад. е&#036;#ть у вас скоростя...

Даж на прошлой странице твоей пук был:

 

Цитата

Агрегация в PTP550  проводится на L1 ( радио) /L2 (  MAC)  уровне.

5 часов назад, Alver сказал:

Метки разделения

Это поэтому проц укатывается в полку?

Т.е. пришедший кадр со свича дерибанится аж до TCP и потом разделяют?

Дебилы шоль?

 

Відредаговано Dimkers
Ссылка на сообщение
Поделиться на других сайтах
1 час назад, Dimkers сказал:

Да? И какой же он уникальный???

Так это было пару дней назад. е&#036;#ть у вас скоростя...

Это поэтому проц укатывается в полку?

Т.е. пришедший кадр со свича дерибанится аж до TCP и потом разделяют?

Дебилы шоль?

 

Вот ты бы перестал популизмом заниматься, а башкой своей подумал. Каждый чейн имеет разные показатели потерь, ошибок и прочей ебатории. А теперь задумайся, какой п@зд#ц был бы, если применить здесь алгоритмы из эзернет сетей, где потери ноль целых х#&#036; десятых.

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

Я раньше пробовал 2 линка с разносом в 700мгц объединять в лаг, и нихера оно не работало. Хуже чем каждый отдельно.

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

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.

  • Схожий контент


×
×
  • Створити нове...