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