[Ilya Evseev]

Имеются два вилана А и Б, в них серверы А1, А2, ..., Б1, Б2, ...

Виланы соединены мостами М1, М2, ...

Как сделать так, чтобы трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д.

При отключении одного из мостов трафик должен идти через один из оставшихся.

Если это принципиально - мосты на FreeBSD.

[XeonVs]

что-то типа lagg(4) с протоколом failover

[voron]

что-то типа lagg(4) с протоколом failover

Каким образом это даст

трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д.

 

[Ilya Evseev]

что-то типа lagg(4) с протоколом failover

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

лишь бы нагрузка между мостами распределялась равномерно

и при отказе одного моста передавалась на другие,

то такая идея имела бы смысл: на коммутаторе в один транк

объединяются интерфейсы всех мостов, глядящие в сеть А,

во второй транк - интерфейсы всех мостов, глядящие в сеть Б.

 

К сожалению, при делении трафика на несколько мостов непонятно,

как сделать них шейпирование, поэтому нужно,

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

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

[RuZzalt]

http://www.unixdoc.ru/index.php?mode=2&amp...eebsd%20openbsd

[Ilya Evseev]

http://www.unixdoc.ru/index.php?mode=2&amp...eebsd%20openbsd

CARP вообще-то предназначен для маршрутизаторов, а не для мостов.

[Lynx10]

Имеются два вилана А и Б, в них серверы А1, А2, ..., Б1, Б2, ...

Виланы соединены мостами М1, М2, ...

Как сделать так, чтобы трафик между А1 и Б1 шел через М1, между А2 и Б2 - через М2 и т.д.

При отключении одного из мостов трафик должен идти через один из оставшихся.

Если это принципиально - мосты на FreeBSD.

на свичах это MSTP

[photon]

К сожалению, при делении трафика на несколько мостов непонятно,

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

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

Все просто. Создаете таблицы IP-адресов и правила для динамических пайпов, и нужные очереди создадутся на шейперах автоматически. В EtherChannel кстати есть возможность определять packet distribution mode (port-channel load-balance ...), если не устраивает стандартный алгоритм, применяемый в LACP. В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.

Изменено 30 декабря, 2009 пользователем photon

[Ilya Evseev]

К сожалению, при делении трафика на несколько мостов непонятно,

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

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

Создаете таблицы IP-адресов и правила для динамических пайпов, и нужные очереди создадутся на шейперах автоматически.

Ага, и если трафик от клиента распараллелится по двум мостам, он получит удвоенную скорость, а если по трём - то утроенную.

Не годится.

[Ilya Evseev]

В 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, но это необходимо проверять.

Интересно, почему нет варианта для равномерной загрузки по числу пакетов/байтов?

[photon]

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

Изменено 30 декабря, 2009 пользователем photon

[photon]

Ага, и если трафик от клиента распараллелится по двум мостам, он получит удвоенную скорость, а если по трём - то утроенную.

Не годится.

Ничего подобного. У меня на прошлой работе так сделана балансировка с несколькими шейперами (без вланов и на EtherChannel, т.к. Cisco), и работает отлично.

Изменено 30 декабря, 2009 пользователем photon

[Ilya Evseev]

То есть итоговая схема получается такой:

все порты, через который мосты воткнуты в первую сеть,

на коммутаторе объединены с помощью LACP в один транк,

а порты, через который они воткнуты во вторую сеть - в другой транк.

Алгоритм агрегации устанавливается в ip_source_dest.

 

That's right? :)

[vitalyb]

В LACP, насколько я помню, хэши для load balancing строятся на основе IP-адресов.

Могу ошибаться, но по-моему к методу балансировки LACP вообще никакого отношения не имеет, зависит исключительно от коммутатора.

 

Интересно, почему нет варианта для равномерной загрузки по числу пакетов/байтов?

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

 

ИМХО в таком "кривом" случае лучше не использовать LACP вообще если есть возможность и использоваться статический link aggregation. С LACP как-то некрасиво получается - мосты должны пропускать LACP PDU насквозь.

 

Алгоритм агрегации устанавливается в ip_source_dest.

Нет, или только source или только destination. Если по обоим сразу - тогда будет удвоенная скорость т.к. два разных соединения в ряде случаев пойдут по разным каналам.

 

 

А может все-таки роутинг? :)

 

[voron]

или только source или только destination

для трафика в мир - source, для трафика из мира - destination.

 

[Ilya Evseev]

ИМХО в таком "кривом" случае лучше не использовать LACP вообще если есть возможность и использоваться статический link aggregation.

Насколько я понимаю, при статическом LA коммутатор не отреагирует на отключение моста.

 

С LACP как-то некрасиво получается - мосты должны пропускать LACP PDU насквозь.

Это, кстати, хороший вопрос - можно ли на коммутаторе объединить по LACP порты, если в них воткнуты несвязанные устройства?

 

А может все-таки роутинг? :)

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

 

или только source или только destination

для трафика в мир - source, для трафика из мира - destination.

Умеет ли это D-Link???

[Ilya Evseev]

Надо какой-то из алгоритмов по 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.

[voron]

или только 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

[Ilya Evseev]

или только source или только destination

для трафика в мир - source, для трафика из мира - destination.

Умеет ли это D-Link???

ip_source и ip_destination это что по-вашему? Не знаю, реально работает оно у вас или нет, но "весчь" есть.

Вопрос был - умеет ли D-Link использовать разные алгоритмы для разных транков?

Насколько я понял, "config link_aggregation algorithm xxx" действует на все транки сразу,

поэтому оптимальный алгоритм по прежнему под вопросом. Наверное, всё же "mac_source_dest".

[[GP]Villi]

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

 

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