bbober25 Posted December 1, 2016 (edited) · Report post Всем привет! Есть задачка, и нужно найти способы решения, а именно: два коммутатора L2 (TpLINK) (территориально удалены друг от друга) Есть два канала L2 (различные, со своей инфраструктуре и пропускной способности) выходящие из первого коммутатора Вопрос: Как объединить эти каналы на втором, удаленном коммутаторе, чтобы в итоге получить один линк? Какие есть варианты объединения этих каналов? Edited December 1, 2016 by bbober25 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ShyLion Posted December 1, 2016 · Report post Есть два канала L2 (различные, со своей инфраструктуре и пропускной способности) выходящие из первого коммутатора Какова структура траффика? Пара маков или целые сегменты? Что внутри кадров? Пара IP или опять-же куча разных? Если пара маков и пара IP, то никак. Round-robin балансировка принесет проблемы из-за несвоевременной доставки кадров. Если пара маков, но куча IP, то балансировка по IP-SRC-DST. Если куча маков, то балансировка по MAC-SRC-DST. Дальше смотри возможности оборудования по port-channel балансировке. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 1, 2016 (edited) · Report post Небольшой поселок (удаленность 200 км), существует канал РРЛ 30 Мб/с (NEC) и канал Wi-Fi 50 Мб/с (Ubiquiti). BRASы (PPPoE) находятся в дата-центре. Планируемое количество абонентов в поселке порядка 300, количество VLAN 3(MGT, Billing, и собственно сам vlan в котором абонент поднимает PPPoE ), каналы различаются только оборудованием и пропускной способностью. Порты на первом коммутаторе (которой в дата-центре) настроены одинаково. В удаленном поселке планируется объединить их, получить один линк, и далее GePon или wi-fi раздать абонентам. Повторюсь, абоненты для подключения используют PPPoE. Т.е. вы предлагаете использовать LACP? Edited December 1, 2016 by bbober25 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Negator Posted December 1, 2016 · Report post раскидате абонентом по двум разным вланам и все. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 1, 2016 · Report post Да, это "решить проблему". Но... РРЛ, все пролеты обеспечиваются гарантированным питанием, а линия, построенная на ubuquiti wi-fi не имеет гарантированного питания, и может отваливаться. Вот и хочется объединить каналы, дабы, при отсутствии одного канала, какая-никакая услуга, но была. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
CityFox Posted December 1, 2016 · Report post Можно на стороне датацентра VLAN c абонентами приходящий через разные каналы терминировать на двух разных PPPoE серверах. Абонент будет работать через тот сервер, ответ от которого пришел первым. Балансировать можно назначая разные задержки PADO delay для разных абонентов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ShyLion Posted December 1, 2016 · Report post Повторюсь, абоненты для подключения используют PPPoE. Т.е. вы предлагаете использовать LACP? Да, с балансировкой по MAC-SRC-DST. В среднем по больнице будет пополам и out-of-order не грозит. Плюс фейловер в случае чего. Нагрузить пропорционально пропускной способности тут сложно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
catalist Posted December 1, 2016 · Report post Вопрос: Как объединить эти каналы на втором, удаленном коммутаторе, чтобы в итоге получить один линк? Патчкордом! :) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 5, 2016 (edited) · Report post В общем ситуация следующая, при соединении кабелем двух коммутаторов и настройкой LACP вроде бы все работает, т.е. 2 хоста ходят только по одному кабелю (скорее всего из-за маленького количества хостов), при пропадании одного канала (отключаем один из кабелей, соединяющие коммутаторы) - канал пропадает на 1 сек, коммутаторы перестраиваются и трафик начинает ходить по второму каналу, оно и логично. Вопрос изначально был в том, что между коммутаторами имеется еще инфраструктура, и коммутаторы удалены друг от друга. На картинке схема для эксперимента, и как оказалось - ШТОРМ ((( Т.е. если в разрыв включить какое-либо устройство коммутации, то данные о LACP не доходят до целевого коммутатора. Какие еще существуют варианты объединения L2 каналов? Edited December 5, 2016 by bbober25 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 5, 2016 (edited) · Report post И так тоже шторм, оно и логично... Ну как же объединить? Хм... Edited December 5, 2016 by bbober25 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 6, 2016 · Report post Уважаемые форумчане! В итоге ситуация решена следующим способом: 1. Если соединять коммутаторы нарямую (без сетевой инфраструктуры между агрегируемыми коммутаторами) то LAG (LACP) настраивается динамический, т.е. на одной стороне Active (отправляет в агрегированный канал данные об агрегации), на другой стороне Passive (принимает из агрегированного канала данные об агрегации), но это, построюсь, только при условии соединения одной средой (медь, оптика). При условии, когда пакеты о наличие LACP не отправляются и не принимаются - образуется петля, и собственно шторм... 2. Второй вариант - это статический LAG (LACP), он не смотрит на наличие пакетов информации о LACP от соседнего коммутатора. Тем самым между коммутаторами возможно добавить разную сетевую инфраструктуру. Всем спасибо, вопрос закрыт. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vurd Posted December 6, 2016 · Report post И когда один из каналов упадет, то статически собранный lag продолжит работать с одной стороны, вопрос опять откроется) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 6, 2016 (edited) · Report post И когда один из каналов упадет, то статически собранный lag продолжит работать с одной стороны, вопрос опять откроется) Т.е.? Что Вы хотите сказать? Если падает один канал, и таблица MAC переписывается на оставшийся канал? При поднятии второго, таблица не распределится? Или я Вас не совсем понял? Edited December 6, 2016 by bbober25 Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Ivan_83 Posted December 6, 2016 · Report post Т.е.? Что Вы хотите сказать? Если падает один канал, и таблица MAC переписывается на оставшийся канал? При поднятии второго, таблица не распределится? Или я Вас не совсем понял? Там принцип другой. В коммутаторе порты объединяются в ОДИН порт, все маки и прочая привязываются к нему ОДНОМУ, когда пакет отправляется через этот порт то от дст мака берётся какой то хэш на основании которого выбирается номер порта через который отправить пакет. В софтварных реализациях ЛАГ есть варианты с раундробином и прочим. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
vurd Posted December 6, 2016 · Report post Т.е.? Что Вы хотите сказать? Если падает один канал, и таблица MAC переписывается на оставшийся канал? При поднятии второго, таблица не распределится? Или я Вас не совсем понял? Этим я хочу сказать, что когда погаснет линк, отмеченный на рисунке у вас перестанет вообще что-либо работать. Ну или останется 50\50, смотря как повезет по hash-алгоритму. Агрегированные каналы должны соединяться порт-порт, иначе не получится в рабочем варианте. Если вы отключили контролирующий протокол LACP, то вы не победили систему, а обманули. Работать в таком варианте будет, только если упадет устройство по середине, за счет чего погаснут порты на обоих ответных сторонах. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 8, 2016 · Report post Агрегированные каналы должны соединяться порт-порт, иначе не получится в рабочем варианте. Если вы отключили контролирующий протокол LACP, то вы не победили систему, а обманули. Работать в таком варианте будет, только если упадет устройство по середине, за счет чего погаснут порты на обоих ответных сторонах. Да, я вас понял, так как устройств промежуточных много и порты не "погаснут" на конечных устройствах, и по хэшу и наличию 2 рабочих портов (несмотря на то, что по пути один из них имеет обрыв), коммутатор будет отправлять пакет в заведомо "нерабочий" порт. Логично... Тогда вопрос остается открытым... Может есть "софтовое" решение этого вопроса? Когда-либо все равно придется сталкиваться сталкиваться с подобными вопросами. Думаем дальше. Вопрос открыт) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
ShyLion Posted December 8, 2016 · Report post Когда-либо все равно придется сталкиваться сталкиваться с подобными вопросами. Думаем дальше. Вопрос открыт) Переходить на L3, протоколы маршрутизации. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 8, 2016 · Report post В том то и дело, если переходить на L3, то придется тащить BRAS, канал связи (обратный) на СОРМ... Надежность падает, ресурс использоваться начинает неэффективно... Не верю, в то что нет решения))) Нужно думать))) Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nkusnetsov Posted December 8, 2016 · Report post bbober25, если в промежутке живет еще какакя-то инфраструктура, проще всего использовать active/backup режим линка. Минус в том, что потеряется часть пропускной способности. Тогда, для мониторинга состояния L2 межу которыми живет инфраструктура надо использовать "arp monitoring". Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
bbober25 Posted December 16, 2016 · Report post В моих TP-LINK'ах невозможно это реализовать. Терять пропускную способность, без того небольшого линка не вариант. Вот же незадача... Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...