Jump to content
Калькуляторы

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

Всем привет!

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

 

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

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

 

Вопрос:

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

Edited by bbober25

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

Небольшой поселок (удаленность 200 км), существует канал РРЛ 30 Мб/с (NEC) и канал Wi-Fi 50 Мб/с (Ubiquiti). BRASы (PPPoE) находятся в дата-центре. Планируемое количество абонентов в поселке порядка 300, количество VLAN 3(MGT, Billing, и собственно сам vlan в котором абонент поднимает PPPoE ), каналы различаются только оборудованием и пропускной способностью. Порты на первом коммутаторе (которой в дата-центре) настроены одинаково. В удаленном поселке планируется объединить их, получить один линк, и далее GePon или wi-fi раздать абонентам. Повторюсь, абоненты для подключения используют PPPoE.

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

Edited by bbober25

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

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

 

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

Share this post


Link to post
Share on other sites

Вопрос:

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

post-138646-034795900 1480897250_thumb.jpg

Edited by bbober25

Share this post


Link to post
Share on other sites

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by bbober25

Share this post


Link to post
Share on other sites

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

Безымянный.png

 

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

post-138646-018632700 1481862686_thumb.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.