URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID1
Нить номер: 95246
[ Назад ]
Исходное сообщение
"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 15:07 
Имеем ubuntu server 12.04.3
настроен bound0 для двух интерфейсов eth0 и eth1 по 802.3ad . Свич настроен соответственно. Транк поднялся - резервирование работает, т.е. дергаешь провада в разных комбинация все как и должно быть. А вот с балансировкой непонятки.

По верх bond0 настроено 3 Vlan`а: Vlan1 - локальная сетка, Vlan2 - первый провайдер, Vlan3 - второй провайдер.
Начинаю тестить - давать нагрузку на сеть через iperf - не суть важно. Ситуация - по пакетам идет почти полная балансировака - принято и отправленно с интерфейсов почти поровну пакетов (погрешность гдето +/- 10 пакетов на 10к) а вот по скорости при этом почти вся нагрузка идет через один из каналов, а на втором какието крохи приблезительно 1-3%
я подозреваю что такая ситуация из-за фрагментации пакета - пробовал играть с mtu на интерфейсах - не помогает - где искать грабли подскажите плиз.

И вторая проблема: во втором vlan через свич бегает мультикаст трафик от провайдера до других устройств в сетке которые в этом же vlan`не. На интерфейсе vlan2 на сервере все хорошо лишнего "шума" нет. Для виртуалзации понадобилось поднять bridge интерфейс на vlan1 интерфейсе. И появилась проблема. Как только подымаеться br0 бриджем на vlan1, vlan2 начинает получать "шум" ввиде этого мультикаст потока, хотя на сервере не используеться ни одного софта для мультикаста и по идее сервер не должен был подлючаться к мультикаст группе на свиче. Собстенно вопрос как от этого избаваться????

Содержание
Сообщения в этом обсуждении
"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 02-Дек-13 19:04 
>[оверквотинг удален]
> первый провайдер, Vlan3 - второй провайдер.
> Начинаю тестить - давать нагрузку на сеть через iperf - не суть
> важно. Ситуация - по пакетам идет почти полная балансировака - принято
> и отправленно с интерфейсов почти поровну пакетов (погрешность гдето +/- 10
> пакетов на 10к) а вот по скорости при этом почти вся
> нагрузка идет через один из каналов, а на втором какието крохи
> приблезительно 1-3%
> я подозреваю что такая ситуация из-за фрагментации пакета - пробовал играть с
> mtu на интерфейсах - не помогает - где искать грабли подскажите
> плиз.

как это пакеты по разным каналам а содержимое по одному? что tcpdump не помогает? почему?

> И вторая проблема: во втором vlan через свич бегает мультикаст трафик от
> провайдера до других устройств в сетке которые в этом же vlan`не.
> На интерфейсе vlan2 на сервере все хорошо лишнего "шума" нет. Для
> виртуалзации понадобилось поднять bridge интерфейс на vlan1 интерфейсе. И появилась проблема.
> Как только подымаеться br0 бриджем на vlan1, vlan2 начинает получать "шум"
> ввиде этого мультикаст потока, хотя на сервере не используеться ни одного
> софта для мультикаста и по идее сервер не должен был подлючаться
> к мультикаст группе на свиче. Собстенно вопрос как от этого избаваться????

зафильтровать мультиувст на бридже.

P.S. bond кривой чуть менее чем полностью надо сказать.
team имеет откровенное кривой userspace -- ходя сам драйвер много лучше

"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 02-Дек-13 19:06 
>[оверквотинг удален]
>> провайдера до других устройств в сетке которые в этом же vlan`не.
>> На интерфейсе vlan2 на сервере все хорошо лишнего "шума" нет. Для
>> виртуалзации понадобилось поднять bridge интерфейс на vlan1 интерфейсе. И появилась проблема.
>> Как только подымаеться br0 бриджем на vlan1, vlan2 начинает получать "шум"
>> ввиде этого мультикаст потока, хотя на сервере не используеться ни одного
>> софта для мультикаста и по идее сервер не должен был подлючаться
>> к мультикаст группе на свиче. Собстенно вопрос как от этого избаваться????
> зафильтровать мультиувст на бридже.
> P.S. bond кривой чуть менее чем полностью надо сказать.
> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше

совсем забыл
есть ещё очень много в openvswitch
например
http://blog.scottlowe.org/2012/10/19/link-aggregation-and-la.../

"Вопрос для истинных гуру сетей или линукса"
Отправлено 2ihi , 02-Дек-13 19:42 
дочитывать не стал, на основе какого алгоритма распределяется трафик? есть по макам, есть по ИП, есть смешанный, может вся проблема в том что балансер срабатывает только на один канал из-за метода распределения? Где-то на циске вроде я видел калькуляторы, достаточно давно и касалось это мультипатчинга в айскази сетях, дак вот там хитро как-то оно разносилось по ифейсам в зависимости от адресов.. Короче говоря смысл моих слов в том что в реальной нагрузке все должно быть хорошо :) распределение трафа будет +\- 3-5%
"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 20:02 
> дочитывать не стал, на основе какого алгоритма распределяется трафик? есть по макам,
> есть по ИП, есть смешанный, может вся проблема в том что
> балансер срабатывает только на один канал из-за метода распределения? Где-то на
> циске вроде я видел калькуляторы, достаточно давно и касалось это мультипатчинга
> в айскази сетях, дак вот там хитро как-то оно разносилось по
> ифейсам в зависимости от адресов.. Короче говоря смысл моих слов в
> том что в реальной нагрузке все должно быть хорошо :) распределение
> трафа будет +\- 3-5%

Распределяеться согласно 802.3ad (LACP). ТО что вы перечислили это другие варианты которые не требуют со стороны свича настройки. Я не понимаю что вы имеете ввиду под реальной нагрузкой? Чем пропихивание пакетов от одной "софтины" будет отличаться от другой. В часности такой транк подымаеться для того чтобы повысить доступность iscsi стора(отказоустойчивая составляющая 802.3ad) и повисить скорость общения со стором(функция агрегирования каналов 802.3ad).

"Вопрос для истинных гуру сетей или линукса"
Отправлено 2ihi , 03-Дек-13 05:26 
> Распределяеться согласно 802.3ad (LACP). ТО что вы перечислили это другие варианты которые
> не требуют со стороны свича настройки. Я не понимаю что вы
> имеете ввиду под реальной нагрузкой? Чем пропихивание пакетов от одной "софтины"
> будет отличаться от другой. В часности такой транк подымаеться для того
> чтобы повысить доступность iscsi стора(отказоустойчивая составляющая 802.3ad) и повисить
> скорость общения со стором(функция агрегирования каналов 802.3ad).

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

имя опыт реализации айсказей на софтовом решении (freebsd+istgt+lagg) скажу, что трафик айсказевый ходит только по одному порту к одной сессии, лоадбалансинга между p2p коннектом нет и не будет.

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

# config sharing address-based (таб)
Next possible completions:
        ip-destination ip-source ip-source-dest mac-destination mac-source
        mac-source-dest

собственно способы хеширования и выбора маршрута..


Под реальной задачей (не в сетях айскази) трафик балансируется поскольку точек (ИП адресов) очень много и вероятность их разбаланситься поровну стремится к единице.

"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 02-Дек-13 20:02 
> дочитывать не стал, на основе какого алгоритма распределяется трафик? есть по макам,
> есть по ИП, есть смешанный, может вся проблема в том что
> балансер срабатывает только на один канал из-за метода распределения? Где-то на
> циске вроде я видел калькуляторы, достаточно давно и касалось это мультипатчинга
> в айскази сетях, дак вот там хитро как-то оно разносилось по
> ифейсам в зависимости от адресов.. Короче говоря смысл моих слов в
> том что в реальной нагрузке все должно быть хорошо :) распределение
> трафа будет +\- 3-5%

на самом деле трафик распределяется на основе значения hash-а -- а вот как оный расчитывается - тут могут быть варианты -- вплоть до l7.

у человека ситуация выглядит дик -- якобы кол-во пакетов примерно одинаково а к-во трафика нет -- хотя...
а да чё хотя -- tcpdump всё покажет

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 20:06 
>[оверквотинг удален]
>>> ввиде этого мультикаст потока, хотя на сервере не используеться ни одного
>>> софта для мультикаста и по идее сервер не должен был подлючаться
>>> к мультикаст группе на свиче. Собстенно вопрос как от этого избаваться????
>> зафильтровать мультиувст на бридже.
>> P.S. bond кривой чуть менее чем полностью надо сказать.
>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
> совсем забыл
> есть ещё очень много в openvswitch
> например
> http://blog.scottlowe.org/2012/10/19/link-aggregation-and-la.../

:) Если вы наведе меня на мысль о том как юзать виртуальный свич для киртуалак для агрегирования реальных каналов который садиться и так по верх bond то буду презнателен.

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 19:54 
>[оверквотинг удален]
>> важно. Ситуация - по пакетам идет почти полная балансировака - принято
>> и отправленно с интерфейсов почти поровну пакетов (погрешность гдето +/- 10
>> пакетов на 10к) а вот по скорости при этом почти вся
>> нагрузка идет через один из каналов, а на втором какието крохи
>> приблезительно 1-3%
>> я подозреваю что такая ситуация из-за фрагментации пакета - пробовал играть с
>> mtu на интерфейсах - не помогает - где искать грабли подскажите
>> плиз.
> как это пакеты по разным каналам а содержимое по одному? что tcpdump
> не помогает? почему?

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

>> И вторая проблема: во втором vlan через свич бегает мультикаст трафик от
>> провайдера до других устройств в сетке которые в этом же vlan`не.
>> На интерфейсе vlan2 на сервере все хорошо лишнего "шума" нет. Для
>> виртуалзации понадобилось поднять bridge интерфейс на vlan1 интерфейсе. И появилась проблема.
>> Как только подымаеться br0 бриджем на vlan1, vlan2 начинает получать "шум"
>> ввиде этого мультикаст потока, хотя на сервере не используеться ни одного
>> софта для мультикаста и по идее сервер не должен был подлючаться
>> к мультикаст группе на свиче. Собстенно вопрос как от этого избаваться????
> зафильтровать мультиувст на бридже.

а чем это поможет?? отфильтровать не проблема но как это спасет от того что в канал всеравно гоняться эти пакеты - по сути отедая полосу. Да основной вопрос - почему они начинают гнаться - насколько я понял чтобы свич начал гнать в канал мультикаст для этого интерфейс должен "подписаться" на свиче в этой мультикастовой группе? Что поднятия бриджа автомотически без участия софта подписываеться на все мультикаст группы?

> P.S. bond кривой чуть менее чем полностью надо сказать.
> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше

Можно по конкретней про team - ссылку на какойнить faq, просто везде по Linux 802.3ad link agregation только bond.

"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 02-Дек-13 20:07 
>[оверквотинг удален]
>> как это пакеты по разным каналам а содержимое по одному? что tcpdump
>> не помогает? почему?
> Пакеты идут по обоим каналам в равном колличественном объеме, а вот в
> в объеме данных нет
> я так подразумеваю что пакет объемем 1500 на какомто этапе бъеться на
> 2 пакета допустим 1400 и 100 они приходят 1 через первый
> интефейс второй через второй (балансировка) т.е. колво пакетов на интерфейсах равное
> а вот размеры пакетов отличаються, но вот из-за чего они могут
> так биться вопрос? тестовые машины на одном свиче. Но это мое
> предположение о возможных причинах может есть и другие :(

tcpdump -- или пакетя отличаются или одно из двух

>[оверквотинг удален]
>>> ввиде этого мультикаст потока, хотя на сервере не используеться ни одного
>>> софта для мультикаста и по идее сервер не должен был подлючаться
>>> к мультикаст группе на свиче. Собстенно вопрос как от этого избаваться????
>> зафильтровать мультиувст на бридже.
> а чем это поможет?? отфильтровать не проблема но как это спасет от
> того что в канал всеравно гоняться эти пакеты - по сути
> отедая полосу. Да основной вопрос - почему они начинают гнаться -
> насколько я понял чтобы свич начал гнать в канал мультикаст для
> этого интерфейс должен "подписаться" на свиче в этой мультикастовой группе? Что
> поднятия бриджа автомотически без участия софта подписываеться на все мультикаст группы?

т.е. изначально в порт мультикаст трафик не льёться? а начинает после поднятия бриджа? и никто не усуществляет подписку? а что за свич такой ? -- а понял -- это в свич прилетает stp и он начинает считать bridge свичём и шлёт на него multicast -- или бридж поднимается с выключеным stp???

>> P.S. bond кривой чуть менее чем полностью надо сказать.
>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
> Можно по конкретней про team - ссылку на какойнить faq, просто везде
> по Linux 802.3ad link agregation только bond.

google же -- ну что вы як маленькие. ну или например modinfo team

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 20:15 
>[оверквотинг удален]
>>> не помогает? почему?
>> Пакеты идут по обоим каналам в равном колличественном объеме, а вот в
>> в объеме данных нет
>> я так подразумеваю что пакет объемем 1500 на какомто этапе бъеться на
>> 2 пакета допустим 1400 и 100 они приходят 1 через первый
>> интефейс второй через второй (балансировка) т.е. колво пакетов на интерфейсах равное
>> а вот размеры пакетов отличаються, но вот из-за чего они могут
>> так биться вопрос? тестовые машины на одном свиче. Но это мое
>> предположение о возможных причинах может есть и другие :(
> tcpdump -- или пакетя отличаются или одно из двух

доеду гляну - вчера все не успел проверить

>[оверквотинг удален]
>> того что в канал всеравно гоняться эти пакеты - по сути
>> отедая полосу. Да основной вопрос - почему они начинают гнаться -
>> насколько я понял чтобы свич начал гнать в канал мультикаст для
>> этого интерфейс должен "подписаться" на свиче в этой мультикастовой группе? Что
>> поднятия бриджа автомотически без участия софта подписываеться на все мультикаст группы?
> т.е. изначально в порт мультикаст трафик не льёться? а начинает после поднятия
> бриджа? и никто не усуществляет подписку? а что за свич такой
> ? -- а понял -- это в свич прилетает stp и
> он начинает считать bridge свичём и шлёт на него multicast --
> или бридж поднимается с выключеным stp???

да бридж поднимаеться с отключенным stp - покрайней мере опция прописана.

>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>> по Linux 802.3ad link agregation только bond.
> google же -- ну что вы як маленькие. ну или например modinfo
> team

Исчу пока инфу

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 20:44 
>[оверквотинг удален]
>>> отедая полосу. Да основной вопрос - почему они начинают гнаться -
>>> насколько я понял чтобы свич начал гнать в канал мультикаст для
>>> этого интерфейс должен "подписаться" на свиче в этой мультикастовой группе? Что
>>> поднятия бриджа автомотически без участия софта подписываеться на все мультикаст группы?
>> т.е. изначально в порт мультикаст трафик не льёться? а начинает после поднятия
>> бриджа? и никто не усуществляет подписку? а что за свич такой
>> ? -- а понял -- это в свич прилетает stp и
>> он начинает считать bridge свичём и шлёт на него multicast --
>> или бридж поднимается с выключеным stp???
> да бридж поднимаеться с отключенным stp - покрайней мере опция прописана.

да + к этому может вы не до поняли
структура такая (приоблезительно)

bond0
|----vlan1
      |--br0
|-----vlan2
|-----vlan3

так вот начинает "фонить" на vlan2, т.е. по идеи br0 его не затрагивает даже если stp включен. Хотя пока писал появилась идея - может поднятие бриджа включет stp по дефолту для всех интерфейсов, а отключение происходить только для vlan1. Доеду попробую поднять для каждого vlan по бриджу с отключение stp. Потом отпишу. Спасибо за наводку - это уже хоть что то - а то просто в тупике был.

>>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>> по Linux 802.3ad link agregation только bond.
>> google же -- ну что вы як маленькие. ну или например modinfo
>> team
> Исчу пока инфу

"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 02-Дек-13 20:49 
>[оверквотинг удален]
> да + к этому может вы не до поняли
> структура такая (приоблезительно)
> bond0
>  |----vlan1
>       |--br0
>  |-----vlan2
>  |-----vlan3
> так вот начинает "фонить" на vlan2, т.е. по идеи br0 его не
> затрагивает даже если stp включен. Хотя пока писал появилась идея -
> может поднятие бриджа включет stp по дефолту для всех интерфейсов, а

не может stp включиться для любых интерфейсов -- stp в linux пока только в рамках bridge-а имеется -- а влиять он может только на ethernet интерфкйсы включенные в этот bridge.
>[оверквотинг удален]
> по бриджу с отключение stp. Потом отпишу. Спасибо за наводку -
> это уже хоть что то - а то просто в тупике
> был.
>>>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>>> по Linux 802.3ad link agregation только bond.
>>> google же -- ну что вы як маленькие. ну или например modinfo
>>> team
>> Исчу пока инфу

мне кажеться что "You are doing it wrong"

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 02-Дек-13 21:08 
>[оверквотинг удален]
>>  |----vlan1
>>       |--br0
>>  |-----vlan2
>>  |-----vlan3
>> так вот начинает "фонить" на vlan2, т.е. по идеи br0 его не
>> затрагивает даже если stp включен. Хотя пока писал появилась идея -
>> может поднятие бриджа включет stp по дефолту для всех интерфейсов, а
> не может stp включиться для любых интерфейсов -- stp в linux пока
> только в рамках bridge-а имеется -- а влиять он может только
> на ethernet интерфкйсы включенные в этот bridge.

Ну как говорить "если программа работает без ошибок, напишите нам что бы мы исправили нанную ошибку". Все может быть bond обеденяет 2 физических ethernet интерфейса, vlan1,2,3 висят по верху, и уже на одном из них висит br0, мб, по вложенности stp мог включить для одного из eth и как следствие начинает дествовать на все "наследники". Проверю - других то вариантов пока вообще нет.


>[оверквотинг удален]
>> это уже хоть что то - а то просто в тупике
>> был.
>>>>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>>>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>>>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>>>> по Linux 802.3ad link agregation только bond.
>>>> google же -- ну что вы як маленькие. ну или например modinfo
>>>> team
>>> Исчу пока инфу
> мне кажеться что "You are doing it wrong"

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 00:02 
>[оверквотинг удален]
>>> это уже хоть что то - а то просто в тупике
>>> был.
>>>>>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>>>>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>>>>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>>>>> по Linux 802.3ad link agregation только bond.
>>>>> google же -- ну что вы як маленькие. ну или например modinfo
>>>>> team
>>>> Исчу пока инфу
>> мне кажеться что "You are doing it wrong"

Итак выше описанный эксперемент проведен - подымался бридж для каждого vlan интерфейса - результат - "мультикастовый шум" появлялся на всех интерфейсах на который вешался бридж.
Печальненко - надо дальше капать

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 00:28 
>[оверквотинг удален]
>>>>>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>>>>>> по Linux 802.3ad link agregation только bond.
>>>>>> google же -- ну что вы як маленькие. ну или например modinfo
>>>>>> team
>>>>> Исчу пока инфу
>>> мне кажеться что "You are doing it wrong"
> Итак выше описанный эксперемент проведен - подымался бридж для каждого vlan интерфейса
> - результат - "мультикастовый шум" появлялся на всех интерфейсах на который
> вешался бридж.
> Печальненко - надо дальше капать

Сам себе отвечаю - полазив по англоязычным форумам, как и предпологал - при подбъеме бриджа автоматически рассылаеться запрос на подключение к мультикаст группам, причем расылаеться от имени физического интерсейса на катором поднят бридж. Объясняют это тем что если этого не делать - потом через бридж не получаеться коректно гнать мультикаст - вот так обозвали глюк фичей и закрепили :(

"Вопрос для истинных гуру сетей или линукса"
Отправлено ACCA , 03-Дек-13 01:19 
802.3ad требует от балансировщика всего две вещи
  1. не менять порядок следования пакетов
  2. не создавать дубликатов

Получится балансировка или нет - вопрос к конкретной реализации. Кури ман от свитча.

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


> это тем что если этого не делать - потом через бридж
> не получаеться коректно гнать мультикаст - вот так обозвали глюк фичей
> и закрепили :(

Не глюк это и не фича, ты просто мешаешь водку (L3) с портвейном (L2).

Мультикаст может быть L2 (Ethernet), а может быть L3 (IP). Приходится догадываться, что от провайдера ты получаешь IP мультикаст. Который может быть завёрнут в Ethernet broadcast (FF:FF:FF:FF:FF:FF), а может в правильный Ethernet multicast, (например 01-00-5E-xx-xx-xx) Если у провайдера своя собственная сетка - ATM, то получишь Ethernet Broadcast без вариантов.

Если до тебя доходит Ethernet broadcast - никуда не денешься, будешь резать файрволом на уровне IP. Если Ethernet multicast - есть варианты вроде ebtables.

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

Есть "свитчи L3", там можешь наворотить фильтрацию по IP, в том числе отлавливать и резать IP-мультикаст или делать из него Ethernet-мультикаст.

"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 03-Дек-13 07:18 
>[оверквотинг удален]
>> Итак выше описанный эксперемент проведен - подымался бридж для каждого vlan интерфейса
>> - результат - "мультикастовый шум" появлялся на всех интерфейсах на который
>> вешался бридж.
>> Печальненко - надо дальше капать
> Сам себе отвечаю - полазив по англоязычным форумам, как и предпологал -
> при подбъеме бриджа автоматически рассылаеться запрос на подключение к мультикаст группам,
> причем расылаеться от имени физического интерсейса на катором поднят бридж. Объясняют
> это тем что если этого не делать - потом через бридж
> не получаеться коректно гнать мультикаст - вот так обозвали глюк фичей
> и закрепили :(

root@sq:~# find /sys/class/net/br0/ | grep multicast
/sys/class/net/br0/bridge/multicast_querier
/sys/class/net/br0/bridge/multicast_query_response_interval
/sys/class/net/br0/bridge/multicast_membership_interval
/sys/class/net/br0/bridge/multicast_router
/sys/class/net/br0/bridge/multicast_startup_query_interval
/sys/class/net/br0/bridge/multicast_last_member_count
/sys/class/net/br0/bridge/multicast_last_member_interval
/sys/class/net/br0/bridge/multicast_startup_query_count
/sys/class/net/br0/bridge/multicast_querier_interval
/sys/class/net/br0/bridge/multicast_query_interval
/sys/class/net/br0/bridge/multicast_snooping
/sys/class/net/br0/statistics/multicast

а конкретно до того как подцепить интерфейсы послть 0 в /sys/class/net/br0/bridge/multicast_router и /sys/class/net/br0/bridge/multicast_querier

"Вопрос для истинных гуру сетей или линукса"
Отправлено pavel_simple , 03-Дек-13 07:24 
>[оверквотинг удален]
> /sys/class/net/br0/bridge/multicast_startup_query_interval
> /sys/class/net/br0/bridge/multicast_last_member_count
> /sys/class/net/br0/bridge/multicast_last_member_interval
> /sys/class/net/br0/bridge/multicast_startup_query_count
> /sys/class/net/br0/bridge/multicast_querier_interval
> /sys/class/net/br0/bridge/multicast_query_interval
> /sys/class/net/br0/bridge/multicast_snooping
> /sys/class/net/br0/statistics/multicast
> а конкретно до того как подцепить интерфейсы послть 0 в /sys/class/net/br0/bridge/multicast_router
> и /sys/class/net/br0/bridge/multicast_querier

P.S.
ip li set dev br0 multicast off allmulticast off
/sys/class/net/br0/bridge/multicast_snooping тоже нужно тушить до того как добавлены интерфейсы

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 13:00 
>[оверквотинг удален]
>> /sys/class/net/br0/bridge/multicast_querier_interval
>> /sys/class/net/br0/bridge/multicast_query_interval
>> /sys/class/net/br0/bridge/multicast_snooping
>> /sys/class/net/br0/statistics/multicast
>> а конкретно до того как подцепить интерфейсы послть 0 в /sys/class/net/br0/bridge/multicast_router
>> и /sys/class/net/br0/bridge/multicast_querier
> P.S.
> ip li set dev br0 multicast off allmulticast off
> /sys/class/net/br0/bridge/multicast_snooping тоже нужно тушить до того как добавлены
> интерфейсы

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

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 00:56 
>[оверквотинг удален]
>>> Пакеты идут по обоим каналам в равном колличественном объеме, а вот в
>>> в объеме данных нет
>>> я так подразумеваю что пакет объемем 1500 на какомто этапе бъеться на
>>> 2 пакета допустим 1400 и 100 они приходят 1 через первый
>>> интефейс второй через второй (балансировка) т.е. колво пакетов на интерфейсах равное
>>> а вот размеры пакетов отличаються, но вот из-за чего они могут
>>> так биться вопрос? тестовые машины на одном свиче. Но это мое
>>> предположение о возможных причинах может есть и другие :(
>> tcpdump -- или пакетя отличаются или одно из двух
> доеду гляну - вчера все не успел проверить

И так глянул - стала понятно откуда ассиметрия объема но норма ли это или нет, не знаю. История такова - через один из eth0 идет входящий трафик, через eth1 исходящий.
Вот такие вот данные - народ подскажите это нормально поведение для LACP?

>[оверквотинг удален]
>> он начинает считать bridge свичём и шлёт на него multicast --
>> или бридж поднимается с выключеным stp???
> да бридж поднимаеться с отключенным stp - покрайней мере опция прописана.
>>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>> по Linux 802.3ad link agregation только bond.
>> google же -- ну что вы як маленькие. ну или например modinfo
>> team
> Исчу пока инфу

"Вопрос для истинных гуру сетей или линукса"
Отправлено fantom , 03-Дек-13 10:57 
>[оверквотинг удален]
>>> он начинает считать bridge свичём и шлёт на него multicast --
>>> или бридж поднимается с выключеным stp???
>> да бридж поднимаеться с отключенным stp - покрайней мере опция прописана.
>>>>> P.S. bond кривой чуть менее чем полностью надо сказать.
>>>>> team имеет откровенное кривой userspace -- ходя сам драйвер много лучше
>>>> Можно по конкретней про team - ссылку на какойнить faq, просто везде
>>>> по Linux 802.3ad link agregation только bond.
>>> google же -- ну что вы як маленькие. ну или например modinfo
>>> team
>> Исчу пока инфу

Повторю одного из предидущих ораторов - все зависит от алгоритма балансировки!

Смотреть надо даташит свича, в который воткнуты шнурки от ваших сетевух,

и смотреть что из следующего свич умеет

EtherChannel load balancing can use MAC addresses; IP addresses; Layer 4 port numbers; either source addresses, destination addresses, or both; or ports.


Или киньте сюда модель свича, коли сами не найдете.

Если свич умеет только "load balancing use MAC addresses" то ничего вы не добьетесь, т.к. при таком балансинге грубо говоря четные МАС-и налево, нечетные - направо и никак иначе ;)

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 12:27 
>[оверквотинг удален]
>>> Исчу пока инфу
> Повторю одного из предидущих ораторов - все зависит от алгоритма балансировки!
> Смотреть надо даташит свича, в который воткнуты шнурки от ваших сетевух,
> и смотреть что из следующего свич умеет
>  EtherChannel load balancing can use MAC addresses; IP addresses; Layer 4
> port numbers; either source addresses, destination addresses, or both; or ports.
> Или киньте сюда модель свича, коли сами не найдете.
> Если свич умеет только "load balancing use MAC addresses" то ничего вы
> не добьетесь, т.к. при таком балансинге грубо говоря четные МАС-и налево,
> нечетные - направо и никак иначе ;)

счас буду искать свичик hp 1810-24g

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 12:53 
>[оверквотинг удален]
>> Повторю одного из предидущих ораторов - все зависит от алгоритма балансировки!
>> Смотреть надо даташит свича, в который воткнуты шнурки от ваших сетевух,
>> и смотреть что из следующего свич умеет
>>  EtherChannel load balancing can use MAC addresses; IP addresses; Layer 4
>> port numbers; either source addresses, destination addresses, or both; or ports.
>> Или киньте сюда модель свича, коли сами не найдете.
>> Если свич умеет только "load balancing use MAC addresses" то ничего вы
>> не добьетесь, т.к. при таком балансинге грубо говоря четные МАС-и налево,
>> нечетные - направо и никак иначе ;)
> счас буду искать свичик hp 1810-24g

Всем спасибо за помощь - нашел и прочитал - данный свич умеет только smac xor dmac - вот и вся балансировка. Все вопрос зарыт, на вторую часть я сам нашел ответ.

"Вопрос для истинных гуру сетей или линукса"
Отправлено izyk , 02-Дек-13 23:58 
About multicast try this:

echo "0"> /sys/devices/virtual/net/br0/bridge/multicast_snooping

and other relative parameters.

"Вопрос для истинных гуру сетей или линукса"
Отправлено KobaLTD. , 03-Дек-13 00:07 
> About multicast try this:
> echo "0"> /sys/devices/virtual/net/br0/bridge/multicast_snooping
> and other relative parameters.

Непомогло :(

"Вопрос для истинных гуру сетей или линукса"
Отправлено me , 03-Дек-13 16:54 
...
> Как только подымаеться br0 бриджем на vlan1, vlan2 начинает получать "шум"

линуксовый бридж выставляет интерфесы в примскьюз мод. Собственно именно так он и работает.
llc-шный обработчик отфильтровывает тарффик по mac-у, мультикаст они не отфльтруют так запросто.