Агрегация/бондинг сквозь промежуточные свичи

На цыске - static etherchannel + load balance src-dst-ip, на линуксе - balance xor с аналогичной балансировкой, все.

Если трафик только с линукса на циску и обратно, то src/dst постоянный, хэш не меняется в каждую сторону используется один линк.

А почему src/dst постоянный? речь же про IP

При отпаде любого линка на дальнем конце вертикально симметричного линка это не задетектится (если только что-то не накостылить). Значит на SW1/SW2 нужна поддержка link state tracking или чего-нибудь аналогичного.

А вообще, зачем тебе так?

Зачем траффик с линукса на цыску? Цыска это свич, она траффик не генерирует, за исключением служебного.

Если автору хочется 2 гбита от одного хоста к другому, то смею его огорчить, такого счастья не будет, особенно с цыской. Разве что в одну сторону (от линукса), если сделать balance-rr и поиметь out-of-order пакеты, то, может быть, получим что-то немногим больше гигабита, в зависимости от. А можем и еще меньше поиметь из-за частых реордеров.

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

bonding в линухе умеет arp monitoring, которым можно мониторить как раз раз цыску через оба линка. Так что если какой-то из них отпадёт, линупс это увидит.

Топология такая, поменять пока не можно.
Есть версия, что гигабитного линка может не хватит под планирующийся объём данных

Потому что «если трафик только с линукса на циску и обратно».

zolden ничего про наличие каких-либо других хостов гуляющих через циску или линукс друг к другу не говорил. (Забавно было бы собрать такую схему для тестирования и зафэйлить то что в целом могло бы как-то работать).

Что-то я с трудом могу нагуглить вариант такого режима на линуксовом бонде
Имеется в виду mode=4 (802.3ad ) и xmit_hash_policy = layer3+4 ?

линупс это увидит

если только что-то не накостылить

Цыска это свич, она траффик не генерирует, за исключением служебного

Ну, раз пошла такая пьянка с фантазиями, то пусть это будет 6513 набитый CSG-ами и пуляющий в linux CDR-ами.

Если автору хочется 2 гбита от одного хоста к другому

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

802.3ad у тебя не заведется т.к. ты не воткнут напрямую в цыску, поэтому нужен статический бондинг\etherchannel.

http://www.kernel.org/doc/Documentation/networking/bonding.txt

	balance-xor or 2

		XOR policy: Transmit based on the selected transmit
		hash policy.  The default policy is a simple [(source
		MAC address XOR'd with destination MAC address) modulo
		slave count].  Alternate transmit policies may be
		selected via the xmit_hash_policy option, described
		below.

		This mode provides load balancing and fault tolerance.

Если хостов несколько, то вполне подойдёт режим который я указал.

Разве что, возможно, придётся подстраивать адреса хостов для того, чтобы они на цыске давали разный хеш и попадали в разные интерфейсы. См команду test etherchannel на цыске:

root-stack-3750x#test etherchannel load-balance interface po1 ip 1.1.1.1 2.2.2.2
Would select Gi2/1/2 of Po1

arp monitoring это не костыль, а вполне распространённое решение, используется в вмварных гипервизорах активно. Что-то подобное есть у цыски для детектирования однонаправленных оптических линков, протокол UDLD.

Давайте без фантазий ;)

Ты уж определись, то ли по «src-dst-ip» то ли по «simple [(source MAC address XOR'd with destination MAC address) modulo slave count]»
Я, конечно не CCNP, но путаницу в показаниях вижу

802.3ad у тебя не заведется

Если те SW1 и SW2 дают transparent L2 - то почему нет?

Мне рассказывали, что в новой(?) линейке продуктов Cisco есть такие «SW[12]», которые типа входят в состав свича слева, т.е. всё выглядит как один большой свич, и lacp должен завестись. Проверяли, но результат мне не рассказывали, если интересно - узнаю.

Я уже сильно забыл cisco, но всё равно хотелось бы уточнить задачу, чтобы были указаны модели cisco и свичей.

Полноценный транк подразумевает нормальную работу при потери одного из линков? Или линки очень надёжные и можно считать, что они всегда работают?

Почему свичи разные?

Отказоустойчивость неактуальна, будем считать их заведомо надёжными => интересует только расширение до 2Г.
Точную модель циски не знаю, думаю что-то типа уровня каталиста 6500
Свичи одинаковые просто их 2...ну так сложилось исторически, модель noname

UDLD — Cisco proprietary, с noname SW1/2 работать не будет.

Если linux умеет BFD, то можно было бы попробовать что-то эдакое замутить. А в целом пахнет EEM/tcl и костылями. По-любому будет дольше чем воткнуть линукс двумя линками в один свич.

Nexus 7k/5k + Nexus 2k и VPC. В имеющихся условиях будет дешевле поставить пару 10GE в линукс и пробросить кабели до циски.

Товарищ, вы читать умеете? Прочитайте описание режима ищщо раз. Причем тут симпл? Там указано, что это просто дефолтный режим, другие выбираются через xmit hash policy, который в режиме layer2+3 примерно равен цысковскому src dst ip.

Да и не важно это в общем, балансировка идет при отправке, прием по всем интерфейсам, так что режимы на цыске и линуксе совпадать ни разу не обязаны. Какой удобнее, тот и выбирай.

Если линки надёжные, настраивайте статическое агрегирование и выбрайте какой подойдёт большей метод балансировки на cisco (src-dst-ip или src-dst-mac).

Как вам уже написали, cisco (не зависимо от того, если у вас SW1 и SW2 или нет) не делает Round-robin балансировку интерфейсов в etherchannel, поэтому один поток данных (одна tcp-сессия) по направлению от cisco к Linux будет не более 1 Гигабита/с. В обратную сторону, вроде, можно включить RR, поэтому с сервера можно будет качать 2 Гигабита/с.

Да я ж только начал!
PAT всего слева от циски и вот тебе одинаковый src ip для всех слева направо :-P

Может и заведется, но я бы такое в продакшен не ставил, стремно. Да и профита особо нет.

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

Ну, не надо было чёрте что в качестве примера выбирать :-Ь

2гбита не будет, я уже выше писал почему. Даже на кроссовере между двумя серверами с 4 гигабитных линков с RR можно снять около 2.5гбит, а если там еще свичи, то все сильно хуже.

Топология следующая:

Топология не понятная - между циской и сервером L2 или L3?

В любом случае где-то тут было сказано, что циска - 65-ый каталист, то вот непосредственно с него:

xxx(config)#port-channel load-balance ?
  dst-ip                 Dst IP Addr
  dst-mac                Dst Mac Addr
  dst-mixed-ip-port      Dst IP Addr and TCP/UDP Port
  dst-port               Dst TCP/UDP Port
  mpls                   Load Balancing for MPLS packets
  src-dst-ip             Src XOR Dst IP Addr
  src-dst-mac            Src XOR Dst Mac Addr
  src-dst-mixed-ip-port  Src XOR Dst IP Addr and TCP/UDP Port
  src-dst-port           Src XOR Dst TCP/UDP Port
  src-ip                 Src IP Addr
  src-mac                Src Mac Addr
  src-mixed-ip-port      Src IP Addr and TCP/UDP Port
  src-port               Src TCP/UDP Port

В зависимости от топологии сети нужно выбрать оптимальный метод балансировки на стороне каталиста. На стороне сервера - то вон написали, что умеет RR.

На SW1 и SW2 есть клиенты, которые должны будут видеть сиську и линукс?
Если нет, то просто подними LACP как если бы они были напрямую соединены.
Если есть, то попробуй LACP поверх VLAN (VLAN_21 - cisco-SW1-linux; VLAN_22 - cisco-SW2-linux). Линукс такое может точно, за циску не буду отвечать (проприетарным дерьмом не увлекаюсь).
Ещё вариант (если есть): LACP как если бы они были напрямую соединены, игнорить (например через mac-фильтрацию или ещё что) пакеты от других компов (хотя не знаю, насколько оно надо) + Подключить ещё по интерфейсу со стороны циски и линукса в sw1 и sw2, и клиентов обслуживать уже на них.

Сразу оговорюсь, что я говорю про L2 сеть с вышеприведеной (автором) конфигурации. А то меня потом кирпичами закидают, т.к. в некоторых особых случаях может быть иначе.

В Вашем случае можно использовать и LB (balance-rr или аналогичные), если только хосты на SW1 и SW2 не будут подключаться к cisco и linux. Ещё момент - судя по сообщению одного очень циско-виндовсного юзера в этом треде, циска не умеет balance-rr или аналог, а то, что она из LB умеет на один комп (с её стороны) точно не поднимет Вам производительности.

Теория:

И да: всякие езерченелы - это проприетарные какашки от циски, которые они хотят заставить всех есть несмотря на наличие нормального LACP.

Всякие rr-методы (xor, dst-mac, dst-ip и прочее) - это вообще не связано с агрегацией как таковой, это нужно (было сделано) для обслуживания множества «тупых» компов (у которых только один порт вообще используется) с балансировкой нагрузки (например, Вам нужно в 8 часов утра отдать 200 метров образа недолинукса по сети, который потом загрузится и подключит юзера с серверу терминалов) на 500 компов. Чтобы всё это не накрылось анусом (и начальство Вас не выкинуло за постоянные ожидания загрузки утром) у Вас в линукс-компе 6 плат 1gbe по 4 порта каждая. 24 этих порта подключены разным свитчам в стеке (поэтому он будет видится в сетевой топологии как один большой). И вот тут Вы начинаете вещать траффик со всех карт в стековый коммутатор. И клиенты (в общем, а не по отдельности) могут получить свои образы со скоростью 24гбит/сек.

Данный пример обычно решается кластеризацией, но он тут просто для примера.

Мало того: при лоад балансе (при подключении только к одному свитчу) Вы не получаете возможность принимать со скоростью большей скорости ОДНОГО порта. Это связано с тем, что у Вас у всех интерфейсов один MAC. Слать (если только в коммутаторе не стоит защита от подмены mac-адресов) Вы можете со всех интерфейсов сразу, коммутатор всё обработает, а вот Вам отсылать он будет на последний порт, с которого была сделана отправка.

Т.е. для любых задач с входящим, а не исходящем трафиком на одном свитче LB - не вариант, нужен LACP, или туннель (VLAN, openvpn, любой другой) между двумя линукс машинами + бондинг, или какашка от циски.

Ещё раз (!!!): АГРЕГАЦИЯ != LOAD BALANCE в большинстве случаев.

точно не поднимет Вам производительности.

Тут я имел в виду производительность сети ОТ cisco К linux. ОТ linux К cisco производительность можно поднять через balance-rr (при условии, что к linux не будут подключаться клиенты с sw1 и sw2).

Чем всё кончилось то?

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

Можешь попробовать загрузить канал на 100%, а дальше посмотреть насколько загружены ресурсы сервера.