[SergKz]

Есть два радиолинка примерно одной пропускной способности, построенные на Ubiquiti - один на мостах 2.4 Ггц, второй на мостах 5 Ггц.

Установлены по одним и тем же конечным точкам, даже на одной мачте с каждой стороны.

Задача: собрать их в агрегированный канал связи так, чтобы:

1) Канал связи продолжал работать при выходе из строя любого из двух радиоканалов. Хорошо бы, чтобы в исправном состоянии пропускная складывалась (баланс трафика?)

2) Внутри агрегированного канала должны работать виланы.

3) Должен быть доступ к управлению самими радиомостами.

 

На столе пока стенд не собирал, решил спросить - вдруг есть готовое типовое решение.

 

Как я пока это себе представляю:

 

Вариант 1

- ставим с двух сторон железки, умеющие VLAN и LACP/Etherchannel (cisco, d-link, mirkotik... их есть... да линукс в конце концов);

- собираем порты, подключенные к радиомостам, в failover trunk;

- внутри транка прокидываем виланы

в этом варианте остаётся открытым вопрос: как управлять мостами? ведь они будут подключены каждый только к части транка, предварительный эксперимент на "живом" микротике, включенном в эту схему, показал, что доступ к устройствам (мостам) теряется, чтобы их настраивать - надо разбирать транк. Может есть какие-то варианты не включать определенные виланы в транк? что будет, если на портах будет разный набор виланов?

 

Вариант 2

- ставим с двух сторон железки, умеющие VLAN и LACP/Etherchannel;

- прокидываем по каждому порту радиоканалов одинаковый набор виланов (один вилан на управление радиобриджами, можно native, два-три рабочих), возможно все с разными номерами;

- собираем в failover trunk ВИЛАНЫ.

при таком подходе управление устройствами должно остаться, но многие ли железки сумеют такой транк?

 

Вариант 3

- ставим с двух сторон железки, умеющие VLAN;

- прокидываем по каждому порту радиоканалов одинаковый набор виланов (один вилан на управление радиобриджами, можно native, два-три рабочих), возможно все с разными номерами;

- за железкой п.1 с каждой стороны ставим вторую, умеющую LACP/Etherchannel - либо роутер (ciso, mikrotik), либо шлюз на линуксе, к которым прокидываем на физпорты развиланенные на первой железке виланы и собираем их в транк.

Тут вроде всё совсем железно должно работать, но наблюдается некоторая избыточность :-)

 

Может есть соображения?

 

(или это надо было в форум "технические вопросы локальных сетей"?)

Изменено 7 октября, 2016 пользователем SergKz

[magnum50]

хотите агрегировать, ставьте с двух сторон cisco и собирайте port-channel ссылка Агрегирование каналов

[Saab95]

Агрегация каналов с не постоянной скоростью возможна по L3 - то есть ставите перед и после микротик, настраиваете 2 подсети /29 на разные порты, в каждый подключаете свою ветку радио. На микротиках настраиваете маршрутизацию, можно динамическую, и будет и резервирование, и суммирование пропускной способности, и даже пропуск трафика в разные стороны по разным каналам. С доступом в интерфейсы управления проблем не будет.

 

Если же нужен L2 канал, то поверх поднимается EoIP туннель, который бриджуется с двух сторон. Если же вся сеть на L2 и нет возможности прописывать какие-то маршруты, тогда на микротике со стороны к центру сети на порту включается прокси-арп, а адресация антенн и дальнего микротика выполняется из-той же сети, используя адреса поштучно, тогда можно иметь доступ в настройки без манипуляций с основной сетью.

[rdc]

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

В силу полудуплексности вайфая, эффективность его работы резко возрастёт.

[SergKz]

хотите агрегировать, ставьте с двух сторон cisco и собирайте port-channel ссылка Агрегирование каналов

 

Именно это я и пробовал в п.1 - после объединения портов в агрегированный канал теряется доступ к самим радиомостам - по "половинке транка" не хочет достукиваться до устройства.

Изменено 8 октября, 2016 пользователем SergKz

[Saab95]

Объедините в транк вланы, тогда доступ до устройств останется.