Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба Имеются два вилана А и Б, в них серверы А1, А2, ..., Б1, Б2, ... Виланы соединены мостами М1, М2, ... Как сделать так, чтобы трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д. При отключении одного из мостов трафик должен идти через один из оставшихся. Если это принципиально - мосты на FreeBSD. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
XeonVs Опубликовано 30 декабря, 2009 · Жалоба что-то типа lagg(4) с протоколом failover Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 30 декабря, 2009 · Жалоба что-то типа lagg(4) с протоколом failoverКаким образом это даст трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба что-то типа lagg(4) с протоколом failoverЕсли бы было неважно, через какой мост пойдут пакеты,лишь бы нагрузка между мостами распределялась равномерно и при отказе одного моста передавалась на другие, то такая идея имела бы смысл: на коммутаторе в один транк объединяются интерфейсы всех мостов, глядящие в сеть А, во второй транк - интерфейсы всех мостов, глядящие в сеть Б. К сожалению, при делении трафика на несколько мостов непонятно, как сделать них шейпирование, поэтому нужно, чтобы трафик между одной парой серверов всегда шёл через один и тот же мост, и передавался на другой, только если первый мост выключен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
RuZzalt Опубликовано 30 декабря, 2009 · Жалоба http://www.unixdoc.ru/index.php?mode=2&...eebsd%20openbsd Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба http://www.unixdoc.ru/index.php?mode=2&...eebsd%20openbsd CARP вообще-то предназначен для маршрутизаторов, а не для мостов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Lynx10 Опубликовано 30 декабря, 2009 · Жалоба Имеются два вилана А и Б, в них серверы А1, А2, ..., Б1, Б2, ...Виланы соединены мостами М1, М2, ... Как сделать так, чтобы трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д. При отключении одного из мостов трафик должен идти через один из оставшихся. Если это принципиально - мосты на FreeBSD. на свичах это MSTP Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 декабря, 2009 (изменено) · Жалоба К сожалению, при делении трафика на несколько мостов непонятно,как сделать них шейпирование, поэтому нужно, чтобы трафик между одной парой серверов всегда шёл через один и тот же мост, и передавался на другой, только если первый мост выключен. Все просто. Создаете таблицы IP-адресов и правила для динамических пайпов, и нужные очереди создадутся на шейперах автоматически. В EtherChannel кстати есть возможность определять packet distribution mode (port-channel load-balance ...), если не устраивает стандартный алгоритм, применяемый в LACP. В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов. Изменено 30 декабря, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба К сожалению, при делении трафика на несколько мостов непонятно,как сделать них шейпирование, поэтому нужно, чтобы трафик между одной парой серверов всегда шёл через один и тот же мост, и передавался на другой, только если первый мост выключен. Создаете таблицы IP-адресов и правила для динамических пайпов, и нужные очереди создадутся на шейперах автоматически. Ага, и если трафик от клиента распараллелится по двум мостам, он получит удвоенную скорость, а если по трём - то утроенную.Не годится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба В EtherChannel кстати есть возможность определять packet distribution mode (port-channel load-balance ...), если не устраивает стандартный алгоритм, применяемый в LACP. В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.Во-первых, у нас коммутатор D-Link, у него в настройках есть LACP, но нет EtherChannel.Правда, там есть такая весчь: #config link_aggregation algorithm ? Command: config link_aggregation algorithm Next possible completions: mac_source mac_destination mac_source_dest ip_source ip_destination ip_source_dest Насколько можно понять, в моём случае оптимальный выбор - mac_source_dest, но это необходимо проверять. Интересно, почему нет варианта для равномерной загрузки по числу пакетов/байтов? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 декабря, 2009 (изменено) · Жалоба Надо какой-то из алгоритмов по ip, потому что мост при отправке пакета меняет mac-адрес на свой. А с другой стороны такой же коммутатор? Иначе может не заработать. Вообще, неплохо бы почитать современную версию стандарта на LACP, может там уже внесли выбор алгоритма, и это не вендор-специфическое расширение. Изменено 30 декабря, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 декабря, 2009 (изменено) · Жалоба Ага, и если трафик от клиента распараллелится по двум мостам, он получит удвоенную скорость, а если по трём - то утроенную.Не годится. Ничего подобного. У меня на прошлой работе так сделана балансировка с несколькими шейперами (без вланов и на EtherChannel, т.к. Cisco), и работает отлично. Изменено 30 декабря, 2009 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба То есть итоговая схема получается такой: все порты, через который мосты воткнуты в первую сеть, на коммутаторе объединены с помощью LACP в один транк, а порты, через который они воткнуты во вторую сеть - в другой транк. Алгоритм агрегации устанавливается в ip_source_dest. That's right? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 30 декабря, 2009 · Жалоба В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.Могу ошибаться, но по-моему к методу балансировки LACP вообще никакого отношения не имеет, зависит исключительно от коммутатора. Интересно, почему нет варианта для равномерной загрузки по числу пакетов/байтов?Потому что при таком подходе есть вероятность изменения порядка пакетов в каждом потоке, что есть большой грех. ИМХО в таком "кривом" случае лучше не использовать LACP вообще если есть возможность и использоваться статический link aggregation. С LACP как-то некрасиво получается - мосты должны пропускать LACP PDU насквозь. Алгоритм агрегации устанавливается в ip_source_dest.Нет, или только source или только destination. Если по обоим сразу - тогда будет удвоенная скорость т.к. два разных соединения в ряде случаев пойдут по разным каналам. А может все-таки роутинг? :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 30 декабря, 2009 · Жалоба или только source или только destinationдля трафика в мир - source, для трафика из мира - destination. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба ИМХО в таком "кривом" случае лучше не использовать LACP вообще если есть возможность и использоваться статический link aggregation.Насколько я понимаю, при статическом LA коммутатор не отреагирует на отключение моста. С LACP как-то некрасиво получается - мосты должны пропускать LACP PDU насквозь.Это, кстати, хороший вопрос - можно ли на коммутаторе объединить по LACP порты, если в них воткнуты несвязанные устройства? А может все-таки роутинг? :)Роутинг используется сейчас. Хочется проверить, насколько повысится быстродействие, если заменить его на бриджинг. или только source или только destinationдля трафика в мир - source, для трафика из мира - destination. Умеет ли это D-Link??? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 30 декабря, 2009 · Жалоба Надо какой-то из алгоритмов по ip, потому что мост при отправке пакета меняет mac-адрес на свой.Ой ли? Мост - это не proxy arp, он работает в promisc-режиме.Сейчас специально проверил Вашу "гипотезу" посредством "tcpdump -e" на компьютерах, пингующих друг друга через мост - принимаемые пакеты имеют mac-адрес настоящего отправителя, а не mac-адрес моста. В принципе, использование proxy arp вместо моста меня бы вполне устроило, но не вполне понятно, как это реализовать на FreeBSD (linux+ebtables rocks?): 1) на ARP-запросы "who_has IP_сервера_А1 tell Б1" и "who_has IP_сервера_Б1 tell А1" мост возвращает свой MAC-адрес, 2) ARP-запросы от A2,A3,,Б2,Б3,... игнорируются - на них отвечают другие мосты, 3) при поступлении пакета от А1 или Б1 мост меняет MAC-адрес получателя на MAC-адрес Б1 или А1 соответственно, 4) после этого пакет отправляется дальше без обработки на layer3. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 31 декабря, 2009 · Жалоба или только source или только destinationдля трафика в мир - source, для трафика из мира - destination.Умеет ли это D-Link??? ip_source и ip_destination это что по-вашему? Не знаю, реально работает оно у вас или нет, но "весчь" есть. Во-первых, у нас коммутатор D-Link, у него в настройках есть LACP, но нет EtherChannel.Правда, там есть такая весчь:#config link_aggregation algorithm ? Command: config link_aggregation algorithm Next possible completions: mac_source mac_destination mac_source_des ip_source ip_destination ip_source_dest Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 31 декабря, 2009 · Жалоба или только source или только destinationдля трафика в мир - source, для трафика из мира - destination.Умеет ли это D-Link??? ip_source и ip_destination это что по-вашему? Не знаю, реально работает оно у вас или нет, но "весчь" есть. Вопрос был - умеет ли D-Link использовать разные алгоритмы для разных транков? Насколько я понял, "config link_aggregation algorithm xxx" действует на все транки сразу, поэтому оптимальный алгоритм по прежнему под вопросом. Наверное, всё же "mac_source_dest". Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
[GP]Villi Опубликовано 31 декабря, 2009 · Жалоба так что вы алгоритмы то обсуждаете, вы проверьте сначала будет ли у вас LACP сквозь мосты работать то, мне почему то кажется что нет, так как LACP возможно только между двумя устройствами его поддерживающем. сам бьюсь над такой же задачей, по сути пакеты от одного хоста и обратно к нему всегда должны ходить через один шейпер, и в случае ната через один нат. пока мне кажется что это решается PBRом на отправляющем устройстве. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...