[AlKov]

"Принимаем" аплинк одним гигабитным портом на D-Link DGS-3120-24TC.

На днях планируется расширение, потребуется собрать агрегацию с еще одним портом.

Вопрос в следующем - возможно ли настроить агрегацию заранее, используя активный порт и при этом не останавливая сервис?

Т.е. например, сконфигурить LACP, назначить активный порт "мастером" и на этом закончить. Что получим в итоге?

[Helios]

Легко. Все будет работать. Пропишите на второй прт такие же вланы, создайте группу, добавьте туда порты. Порт который сейчас активен сделайте мастером. Только ЗАРАНЕЕ решите, будет у вас просто static агрегация или LACP. Ибо потом не поменять - только через удаление группы.

[sio]

Т.е. например, сконфигурить LACP, назначить активный порт "мастером" и на этом закончить. Что получим в итоге?

Вы получите down своего единственного рабочего интерфеса, ибо lacp с вашей стороны очень захочет lacp с удаленной.

[AlKov]

Вы получите down своего единственного рабочего интерфеса, ибо lacp с вашей стороны очень захочет lacp с удаленной.

Вот этого я и опасаюсь..

Вроде как есть решение -

2.2. Режим работы

Как это принято со многими другими протоколами, LACP может быть настроен в двух режимах: активный(active) и пассивный(passive). В активном режиме сразу после настройки протокола по настроенным портам начинают передаваться кадры LACP в поисках LACP-соседа на другой стороне. Тогда как в пассивном режиме, сразу после настройки никаких кадров согласования не посылает и настроеное устройство терпеливо ждёт когда active-сосед с другой стороны его найдёт. До тех самых пор каналы будут жить как отдельные и важно, так как если мы настраиваем агрегацию на эксплуатируемых узлах, после установки passive-режима не произойдёт разрыва, как было бы в случае установки режима active и безуспешного поиска LACP-соседа.

Но статья для Cisco. Есть ли такая возможность (изменить режим LACP на passive) для DGS-3120?

[passer]

Вы получите down своего единственного рабочего интерфеса, ибо lacp с вашей стороны очень захочет lacp с удаленной.

Не получит. Во всяком случае с lacp. Видимо вы не работали с этим коммутатором. Если линк имеется только на одном порту группы - коммутатор DGS-3120 не настаивает на наличии lacp с другой стороны и все работает. Поднялся второй линк или более, вот тогда да, lacp с другой стороны необходим.

Т.е. в случае с DGS-3120 следует следовать (во каламбур получился) рекомендациям Helios и все будет работать.

 

Lacp на DGS-3120 обычно настраиваю в режим active, проблем не бывает. 

 

 

Edited August 3, 2012 by passer

[AlKov]

Если линк имеется только на одном порту группы - коммутатор DGS-3120 не настаивает на наличии lacp с другой стороны и все работает. Поднялся второй линк или более, вот тогда да, lacp с другой стороны необходим.

Т.е. цитата, приведенная мной, особенно вот эта часть

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

100% не имеет отношения для DGS-3120 и справедлива только для Cisco?

 

P.S. До настройки агрегации со стороны провайдера, конфигурация активного порта изменятся не будет, второй порт вообще будет в down.

Edited August 4, 2012 by AlKov

[passer]

Цитата справедлива для Cisco, ZTE, по-моему, Edge Core, вероятно еще некоторых вендоров. Но именно для D-Link DGS-3120 - не справедливо. У меня умолчательная настройка DGS-3120 - lacp по портам 1-2. И я никогда не заморачиваюсь при первичной сборке стенда или стойки подключением дополнительных патчкордов или настройкой lacp на другой стороне.

Edited August 4, 2012 by passer

[sio]

Я действительно не работал D-Link DGS-3120, и понятия не имею, откуда взята цитата на русском. Cisco.com однозначно заявляет, что есть только три рабочих режима lacp: active-active, active-passive и on-on, но последний вообще без lacp. Строить сеть на проприетарных фичах чревато, на проприетарных багах - даже не знаю.

[passer]

Строить сеть на проприетарных фичах чревато, на проприетарных багах - даже не знаю.

Согласен. Но сейчас речь о том, чтобы переключиться без временного прекращения сервиса. И если китайский программер оставил лазейку - почему ею не воспользоваться?

[sio]

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

Нормальная такая лазейка, вы односторонний линк никогда не ловили? а односторонний линк интерфейса в бандле? Главное - не понятно зачем заранее писать lacp, аплинк ведь тоже его будет настраивать, настраивайте вместе с ним. Если делать согласованно, то перерыв будет несколько секунд.

[AlKov]

[Главное - не понятно зачем заранее писать lacp, аплинк ведь тоже его будет настраивать, настраивайте вместе с ним. Если делать согласованно, то перерыв будет несколько секунд.

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

[sio]

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

Да легко:

- прописываете новый интерфейс с active lacp;

- рабочий vlan оставляете и на старом интерфейсе и добавляете в группу;

- у аплинка прописывается новый интерфейс с active lacp, но рабочий vlan не добавляется;

- поднимается новый инттерфейс, проверяется корректность работы lacp, до этого момента перерыва в работе нет;

- у аплинка рабочий vlan удаляется со старого интерфейса и добавляется в группу, если там роутер, то переносится ip адрес - перерыв 1 секунда, ну две, если оператор не ловкий;

- старый интерфейс добавляется в группу - всё.

 

Если поднят BGP, то надо добавить что-то типа fast-external-fallover disable, чтобы сессия не падала.

[AlKov]

Да легко:

- прописываете новый интерфейс с active lacp;

- рабочий vlan оставляете и на старом интерфейсе и добавляете в группу;

- у аплинка прописывается новый интерфейс с active lacp, но рабочий vlan не добавляется;

- поднимается новый инттерфейс, проверяется корректность работы lacp, до этого момента перерыва в работе нет;

- у аплинка рабочий vlan удаляется со старого интерфейса и добавляется в группу, если там роутер, то переносится ip адрес - перерыв 1 секунда, ну две, если оператор не ловкий;

- старый интерфейс добавляется в группу - всё.

 

Если поднят BGP, то надо добавить что-то типа fast-external-fallover disable, чтобы сессия не падала.

Все совсем не так, или почти не так. У аплинка в нашу сторону ADM16/1, что дальше (где L3) не знаю. Vlan как таковые отсутствуют. BGP тоже нет.

Ну проблему с нахождением "одновременно в двух местах", надеюсь решить. На узле подключения есть наше свободное волокно, захвачу с собой ноут и по нему доберусь до своего DGS-3120. Соответственно эксперимент с предварительной настройкой отменяется.

Зато появилась другая задача, которую надо правильно решить.

Дело в том, что в единственном кабеле (4-ка), которым мы заходим на узел аплинка, два волокна "под вопросом" (большие потери), а порт берём двумя волокнами, т.е запасу нема.. Поэтому принято решение заменить кабель на 8-ку (вот тогда-то и появится то свободное волокно, о котором я писал выше) и первоначально собрать агрегацию "на двух кабелях" - два волокна из "старого" временно так и остаются, а два волокна из "нового" пойдут на второй порт. "Старый" кабель впоследствии необходимо убрать. Вот с этого момента и начинается задача - как необходимо сконфигурить LACP на DGS-3120 так, чтобы без перерыва перейти полностью на новый кабель. Для этого необходимо переварить в промежуточной муфте два волокна (из старого на новый).

Т.е. какое-то время придется работать на одном порту с уже сконфигуренным LACP.

Здесь наверное будет иметь значение только назначение "мастер" порта? Например, сейчас (один порт без LACP) работает порт 23, добавлять буду 24-й. Какой из них делать "мастером", учитывая то, что "ломать" будем 23-й? Я првильно понимаю, что в этом случае "мастером" должен быть 24-й порт? Что-то еще в конфигурации может иметь значение в данном случае?

[AlKov]

Возникла новая заморочка с агрегацией на DGS-3120-24TC.

Кроме агрегации с провайдером (ТТК), необходимо на этом же коммутаторе агрегировать еще два порта с роутера на CentOS 6.3.

Проблема в том, что на CentOS доступно только два алгоритма агрегирования, полностью совместимых с 802.3ad (LACP) -

layer2

               Uses XOR of hardware MAC addresses to generate the
               hash.  The formula is

               (source MAC XOR destination MAC) modulo slave count

               This algorithm will place all traffic to a particular
               network peer on the same slave.

               This algorithm is 802.3ad compliant.

layer2+3

               This policy uses a combination of layer2 and layer3
               protocol information to generate the hash.

               Uses XOR of hardware MAC addresses and IP addresses to
               generate the hash.  The formula is

               (((source IP XOR dest IP) AND 0xffff) XOR
                       ( source MAC XOR destination MAC ))
                               modulo slave count

В "интерпретации" DGS-3120 есть 6 алгоритмов:

1. mac_source
2. mac_destination
3. mac_source_dest
4. ip_source
5. ip_destination
6. ip_source_dest

Как я понимаю, в данном случае совместимость можно обеспечить только в случае layer2 со стороны CentOS и mac_source_dest со стороны DGS-3120.

Всё бы ничего, но пока не знаю, какой алгоритм агрегирования будет со стороны ТТК, сильно подозреваю, что ip_source_dest.

Что-нибудь, кроме переноса одного из линков на другой коммутатор, возможно сделать в этом случае?

[dmvy]

алгоритм балансировки влияет только на исходящий трафик. с двух сторон можно настраивать любой способ балансировки.

 

мы удаленно на лету уже множество раз переводили линки на LACP между dlink - dlink и cisco - dlink. все реально простой примерно 10 секунд (в большой степени влияет скорость поднятия ether channel интерфейса на cisco). если второй линк еще не подключен, то мы его заочно добавляем в linkagg и связь происходит через один активный линк.

[AlKov]

алгоритм балансировки влияет только на исходящий трафик. с двух сторон можно настраивать любой способ балансировки.

И..?? Что Вы этим хотите сказать? То, что "работать будет", или "будет, но не так, как хотелось бы"?

Потом - "исходящий" - это для кого? Если для нас, как провайдера, то это "совсем не есть гуд", т.к. сиё будет как раз "входящим для клиента".

мы удаленно на лету уже множество раз переводили линки на LACP между dlink - dlink и cisco - dlink. все реально простой примерно 10 секунд (в большой степени влияет скорость поднятия ether channel интерфейса на cisco). если второй линк еще не подключен, то мы его заочно добавляем в linkagg и связь происходит через один активный линк.

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

Если "верхний провайдер" затребует тот тип агрегации, о котором я уже упоминал, будет ли ВСЁ вышеозвученное работать "как надо", или тут однозначно - "как получится"?

Очень хотелось бы первого. :)

 

P.S.

Вся эта "затея" создана с целью выдать "вниз" (к абонентам) более 1 Gb/s, где ~ 800 Mbit/s будет "Интернетов" и + локальный P2P (торрент трекер) и прочие "локальные сервисы".

Последний НЕ должен создавать проблем для "Интернетов" и "ходить сам по себе" (ну как кошка :-)).

Edited August 27, 2012 by AlKov

[martin74]

Алгоритм балансировки влияет на исходящий из порта трафик. Если вам провайдер будет балансировать по макам, а вы - по ипсорсе+ипдест - то все будет работать.

Требования выставлять с обоих сторон линка одинаковый алгоритм балансировки - нет.

[AlKov]

Алгоритм балансировки влияет на исходящий из порта трафик. Если вам провайдер будет балансировать по макам, а вы - по ипсорсе+ипдест - то все будет работать.

Требования выставлять с обоих сторон линка одинаковый алгоритм балансировки - нет.

Но судя по тому, что Вы написали - "Если вам провайдер будет балансировать по макам, а вы - по ипсорсе+ипдест - то все будет работать" - определенная зависимость существует?

И вот в этом месте я существенно плаваю..

Вы не подскажете, как правильно сконфигурить алгоритмы балансировки на CentOS и DGS-3120 для AGR GROUP 1 и AGR GROUP 2 в нижеследующей схеме?

[passer]

На центосе layer2+3, и l4_src_dest_port или ip_source_dest на DGS-3120. При необходимости тип баллансировки всегда можно поменять.

 

Провайдеру в принципе все равно каким алгоритмом вы баллансируете. А у себя он, вероятно, поставит L3+L4 или аналог.

 

 

Edited August 27, 2012 by passer

[martin74]

нету там зависимости. Как провайдер вам отбалансирует - так вы входящий трафик и получите. А как вы сбалансируете - так провайдер от вас и получит.

[AlKov]

нету там зависимости. Как провайдер вам отбалансирует - так вы входящий трафик и получите. А как вы сбалансируете - так провайдер от вас и получит.

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

А в чем же тогда тайный смысл такого разнообразия алгоритмов балансировки, если согласования сторон по этому пункту не требуется?

[martin74]

а что производитель реализовал - тем и пользуемся ;)

Трафик - он знаете ли разный бывает... Иногда достаточно по макам отбалансировать, а иногда надо и по адресам... Все от конкретной ситуации зависит.. И от ваших желаний и возможностей. Я например, когда lacp использую - стараюсь порты поровну грузить. А иногда достаточно и одного порта, а второй нужен только, если сломалось....

[AlKov]

а что производитель реализовал - тем и пользуемся ;)

Трафик - он знаете ли разный бывает... Иногда достаточно по макам отбалансировать, а иногда надо и по адресам... Все от конкретной ситуации зависит.. И от ваших желаний и возможностей. Я например, когда lacp использую - стараюсь порты поровну грузить. А иногда достаточно и одного порта, а второй нужен только, если сломалось....

Ну мне однозначно нужно "сделать толще". В этом случае какая балансировка предпочтительнее? Или снова неопределенно, "подкручиваем по результату"?

В чем могут быть проблемы, и на какие "показатели" надо будет обращать внимание?

[martin74]

По результату ;)

[Garra-67]

Пречитал но так толком и не понял в итоге. Задача сагрегировать 2 гига от сервера с дебианом к длингу 3627.

На сервере будет bonding посредством ifenslave. Как уже писали у длинга есть 6 режимов, так какой в итоге ставить?

На серверах будет файлохран и скорость критически важна. 10Г адаптеры поставить нет возможности.