Я собираюсь соединить два коммутатора (CRS226-24G-2S+RM), чтобы они работали как один. К сожалению, у меня нет опыта в объединении коммутаторов Mikrotik. Могу ли я использовать этот оптический кабель http://routerboard.com/SplusDA0003? Если нет, какая будет лучшая опция для обеспечения максимальной скорости между этими двумя коммутаторами? Спасибо!
Похоже, что ЧАСТИЧНАЯ задержка реализована на аппаратном уровне. Вот часть недавнего письма, которое я получил от поддержки:
От: MikroTik support [Janis B.] [support@mikrotik.com] Дата: четверг, 20 ноября 2014, 00:20 Тема: Re: [Ticket#] IEEE 802.3ad Динамическое объединение каналов в CRS226?
Здравствуйте, Пока нет сроков внедрения динамического объединения каналов на уровне чипа в коммутаторах CRS. Вы пробовали тестировать напрямую подключённый CRS-транк с группой портов 802.3ad на Synology NAS? Там совсем нет соединения или просто не работает балансировка?
Мы тестировали транки CRS с LACP-линками других производителей, балансировка всё равно работала, даже если LACP показывал сбой. Я сам жду настоящей поддержки LACP на аппаратном уровне чипа.
Я даже купил коммутатор другой марки, чтобы поставить его между Mikrotik и NAS. Знаете что? Пока NAS нормально подключается по LACP к новому коммутатору, а вот создать объединённый канал с нового коммутатора на CRS так и не удалось.
Писал в поддержку несколько раз, надеюсь скоро получить ответ.
barkas, почему я не должен использовать коммутаторы Mikrotik? Они дают мне 24 порта, которые работают на скорости проводного соединения, к тому же у меня есть доступ к функциям маршрутизатора (как ты и сказал). Что в этом плохого? Кроме того, это очень круто — иметь коммутатор с возможностями маршрутизатора. Также мне очень нравится идея увидеть 48-портовые коммутаторы от Mikrotik.
Коммутатор на базе CRS поддерживает агрегацию портов (trunking). Он обеспечивает резервирование и равномерно распределяет исходящие пакеты по каждому порту в составе тринка. То есть, если ваш коммутатор перенаправляет 1000 пакетов с ether1 на trunk ether2+ether3, он отправит по 500 пакетов на ether2 и 500 пакетов на ether3. Аппаратная поддержка LACP отсутствует, или, по крайней мере, средства управления им не реализованы в RouterOS. Источник: http://wiki.mikrotik.com/wiki/Manual:CRS_examples#Trunking
tirkitneth, да, но как работать с master-port? Как сказать другим портам использовать trunk в качестве master-port? Потому что сейчас, когда я выбираю master port, в списке вижу только ether-порты.
Если переключать пакеты между ether1 и trunk1=ether2+ether3, то можно установить master-port=ether1 на ether2 и ether3. Если же вы хотите маршрутизировать пакеты по транку, то я не знаю. Использовать CRS как роутер я не планирую.
К сожалению, STP — одна из многих функций, отсутствующих в CRS. Жаль для управляемого коммутатора, но с одной стороны это как-то понятно при такой цене.
Нет, это не так. Даже самый дешевый управляемый коммутатор, например от netgear, поддерживает STP. Без этого невозможно создать отказоустойчивость, так что такой коммутатор как устройство бесполезен.
Я уверен, что RouterOS уже поддерживает STP/RSTP в режиме мостов, но про работу в режиме коммутатора я не знаю. STP/RSTP не нужен, если вы соединяете коммутаторы по звездообразной топологии. Если же вы соединяете коммутаторы так, что образуется петля, тогда STP необходим. Однако если у вас петля на CCR, можно использовать мост с включённым STP там, и тогда на коммутаторах это делать не придётся. Что касается альтернативных производителей, которых вы перечислили, то из опыта скажу — не берите dlink или netgear. Netgear, конечно, работает, но в крупных сетях показывает себя плохо, а коммутаторы dlink недостаточно производительны.
Все современные коммутаторы без проблем работают на полной скорости. Самая распространённая топология сети — звезда, и это хорошее решение, но в корпоративных сетях хочется, чтобы всё было с резервированием. А это значит, что нужно удвоить core-коммутаторы и access-коммутаторы, а значит, появятся петли, а вместе с ними — STP, мульти-чейзис LAG или что-то в этом духе. Лично я бы использовал управляемые коммутаторы TP-Link за низкую цену, потому что у них CLI, похожий на Cisco. Если есть возможность — лучше настоящие устройства, то есть Cisco, Juniper или что-то подобное. Ни в коем случае не MikroTik из-за недостатка функций, да и VLAN на CRS — настоящее мучение.