Объединение L2 каналов

[bbober25]

Всем привет!

Есть задачка, и нужно найти способы решения, а именно:

 

два коммутатора L2 (TpLINK) (территориально удалены друг от друга)

Есть два канала L2 (различные, со своей инфраструктуре и пропускной способности) выходящие из первого коммутатора

 

Вопрос:

Как объединить эти каналы на втором, удаленном коммутаторе, чтобы в итоге получить один линк? Какие есть варианты объединения этих каналов?

Edited December 1, 2016 by bbober25

[ShyLion]

Есть два канала L2 (различные, со своей инфраструктуре и пропускной способности) выходящие из первого коммутатора

 

Какова структура траффика? Пара маков или целые сегменты?

Что внутри кадров? Пара IP или опять-же куча разных?

 

Если пара маков и пара IP, то никак. Round-robin балансировка принесет проблемы из-за несвоевременной доставки кадров.

Если пара маков, но куча IP, то балансировка по IP-SRC-DST. Если куча маков, то балансировка по MAC-SRC-DST.

Дальше смотри возможности оборудования по port-channel балансировке.

[bbober25]

Небольшой поселок (удаленность 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

[Negator]

раскидате абонентом по двум разным вланам и все.

[bbober25]

Да, это "решить проблему". Но... РРЛ, все пролеты обеспечиваются гарантированным питанием, а линия, построенная на ubuquiti wi-fi не имеет гарантированного питания, и может отваливаться. Вот и хочется объединить каналы, дабы, при отсутствии одного канала, какая-никакая услуга, но была.

[CityFox]

Можно на стороне датацентра VLAN c абонентами приходящий через разные каналы терминировать на двух разных PPPoE серверах.

Абонент будет работать через тот сервер, ответ от которого пришел первым. Балансировать можно назначая разные задержки PADO delay для разных абонентов.

[ShyLion]

Повторюсь, абоненты для подключения используют PPPoE.

Т.е. вы предлагаете использовать LACP?

Да, с балансировкой по MAC-SRC-DST. В среднем по больнице будет пополам и out-of-order не грозит. Плюс фейловер в случае чего.

 

Нагрузить пропорционально пропускной способности тут сложно.

[catalist]

Вопрос:

Как объединить эти каналы на втором, удаленном коммутаторе, чтобы в итоге получить один линк?

Патчкордом! :)

[bbober25]

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

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

На картинке схема для эксперимента, и как оказалось - ШТОРМ (((

Т.е. если в разрыв включить какое-либо устройство коммутации, то данные о LACP не доходят до целевого коммутатора.

Какие еще существуют варианты объединения L2 каналов?

Edited December 5, 2016 by bbober25

[bbober25]

И так тоже шторм, оно и логично... Ну как же объединить? Хм...

Edited December 5, 2016 by bbober25

[bbober25]

Уважаемые форумчане!

В итоге ситуация решена следующим способом:

1. Если соединять коммутаторы нарямую (без сетевой инфраструктуры между агрегируемыми коммутаторами) то LAG (LACP) настраивается динамический, т.е. на одной стороне Active (отправляет в агрегированный канал данные об агрегации), на другой стороне Passive (принимает из агрегированного канала данные об агрегации), но это, построюсь, только при условии соединения одной средой (медь, оптика). При условии, когда пакеты о наличие LACP не отправляются и не принимаются - образуется петля, и собственно шторм...

2. Второй вариант - это статический LAG (LACP), он не смотрит на наличие пакетов информации о LACP от соседнего коммутатора. Тем самым между коммутаторами возможно добавить разную сетевую инфраструктуру.

Всем спасибо, вопрос закрыт.

[vurd]

И когда один из каналов упадет, то статически собранный lag продолжит работать с одной стороны, вопрос опять откроется)

[bbober25]

И когда один из каналов упадет, то статически собранный lag продолжит работать с одной стороны, вопрос опять откроется)

Т.е.? Что Вы хотите сказать? Если падает один канал, и таблица MAC переписывается на оставшийся канал? При поднятии второго, таблица не распределится?

Или я Вас не совсем понял?

Edited December 6, 2016 by bbober25

[Ivan_83]

Т.е.? Что Вы хотите сказать? Если падает один канал, и таблица MAC переписывается на оставшийся канал? При поднятии второго, таблица не распределится? Или я Вас не совсем понял?

Там принцип другой.

В коммутаторе порты объединяются в ОДИН порт, все маки и прочая привязываются к нему ОДНОМУ, когда пакет отправляется через этот порт то от дст мака берётся какой то хэш на основании которого выбирается номер порта через который отправить пакет.

В софтварных реализациях ЛАГ есть варианты с раундробином и прочим.

[vurd]

Т.е.? Что Вы хотите сказать? Если падает один канал, и таблица MAC переписывается на оставшийся канал? При поднятии второго, таблица не распределится?

Или я Вас не совсем понял?

 

Этим я хочу сказать, что когда погаснет линк, отмеченный на рисунке у вас перестанет вообще что-либо работать. Ну или останется 50\50, смотря как повезет по hash-алгоритму.

 

 

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

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

[bbober25]

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

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

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

Тогда вопрос остается открытым... Может есть "софтовое" решение этого вопроса?

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

Думаем дальше. Вопрос открыт)

[ShyLion]

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

Думаем дальше. Вопрос открыт)

 

Переходить на L3, протоколы маршрутизации.

[bbober25]

В том то и дело, если переходить на L3, то придется тащить BRAS, канал связи (обратный) на СОРМ... Надежность падает, ресурс использоваться начинает неэффективно...

Не верю, в то что нет решения))) Нужно думать)))

[nkusnetsov]

bbober25, если в промежутке живет еще какакя-то инфраструктура, проще всего использовать active/backup режим линка. Минус в том, что потеряется часть пропускной способности. Тогда, для мониторинга состояния L2 межу которыми живет инфраструктура надо использовать "arp monitoring".

[bbober25]

В моих TP-LINK'ах невозможно это реализовать. Терять пропускную способность, без того небольшого линка не вариант.

Вот же незадача...