Здравствуйте. Есть одна очень интересная задача с дублирование всего и вся. Но прежде чем расписывать всю конфигурацию , есть 1 конткретный вопрос: вот есть микротик, и есть некий L3 коммутатор (может и не l3, но в данной лабе это именно он) У микрота допустим 2 порта ether2 и 3 , они заведены на свич чип(ether2-master) и плюс еще в бридж оба. На бридже адрес допустим 10.168.1.2/24 на этот бридж навешан vrrp интерфейс с адресом 10.168.1.254 (где сейчас второй vrrp не важно) и на этот vrrp навешаны несколько vlan интерфейсов (это которые с тегом кадр шлют). На коммутаторе тоже настроен транковый порт, допустим 25 в сторону микротика (vlan 101,102 tagged 25 как-то так). Т.е еще раз между микротиком и коммутатором транк. вешаем на vrrp еще 1 адрес 10.168.102.254 (это подсеть 102 влана например). Воткнем компутер в порт коммутатора, который в vlan 1 и получает по dhcp адрес шлюза 10.168.1.254 Все ок, все пингуется. Делаем порт в 102 влане и все , финиш, трафик не в 1 влане между микротом и коммутатором (включал торч на 102 интерфейсе) не ходит, маков нет. Собстно вопрос: будут ли ходить тегированные фреймы между микротиком и коммутатором, если на микротике порт в свиче, тот в бридже, а тот в vrrp ? Реальная задача и конфигурация этой лабы гораздо больше, но пока такой локальный вопрос. Если не понятен конфиг, говорите, выложу полную картинку, но тогда тема переедет в маршрутизацию.
И имеем петлю в чистом виде. Грубо, у вас бридж, это программный свитч. т.е. имея 2 2-портовых свитча вы соединили их двумя аплинками.
пробовал и без бриджа и только бридж, все равно другие вланы не ходят. Да даже если петля, там везде stp и loop-protected включены, онако отключений портов не было.
тут вопрос ключевой что с вланом при бридже\свиче произойдет, он улетит в 2 порта сразу, на части раздробиться или то-то еще, они же не в бондинге.
а это дальнейшая часть истории=) пока остановимся на локальной задаче. Я знаю что на vlan нельзя повесить vrrp, но наоборот вроде можно.
Я бы не стал вешать VLAN на VRRP. Я бы повесил их на основной интерфейс и, возможно, воспользовался скриптами на VRRP-интерфейсе на события on-master и on-slave
а если физ.интерфейсы в бридже? 2 и 3 например и микротик не ругается когда vlan на vrrp вешаешь , но кадры не ходят и неясно где ошибка. Для полноты картины вот картинка. Если не углубляться в философию зачем такое надо итд, вроде картинка как по учебнику. Смотрите, порты 2,3 на микротиках объеденены в свич (2 порт master), этот же 2-й порт в бридже и на него (бридж) навешан ip адрес какой-то (разные на разных микротиках), на этот бридж повешан vrrp , с адресом например 10.168.1.254/24 в 1 vlan-е. на L3 коммутаторах в 1 влане тоже некие адреса + адреса default GW для вланов (конечные устройства получают параметры сети по dhcp от микротиков), так же на этих коммутаторах default GW указан 10.168.1.254 (vrrp который). Так вот, если конечное устройство в 1 влане и ему передается default GW 10.168.1.254 , то все ок, любой обрыв,отказ и восстановление отрабатывается успешно. Но как только устаройство в влане например 102 получает default GW 10.168.102.1 (а он задан на обоих коммутаторах одинаково , и тут нас спасает stp), то начинается вакханалья. То пинги в пределах сети больше 1мс, и не обрабатывается возвраз одного из l3 свичей в работу, а вот обрыв, отказ обрабатывается успешно. Я пробовал просто повесить еще 1 ip на vrrp интерфейс , и для каждого влана указывать его шлюзом, но опять же почему не ходят другие вланы между микротиком и l3 свичем?
Добавлю, что на микротиках маршруты в сети этих вланов указаны как 2шт с разными дистанциями к ip коммутаторов в 1 влане соотственно.
Вы рискуете указав пару интерфейсов в VRRP встать на следующее. Если у вас интерфейсы отвалятся "крест на крест", то будет проблема. Правильно ставить в VRRP один интерфейс и крутить скрипты
проблема не очень навредит, интернеты будут. Т.к по stp все равно будет "активным" только 1 коммутатор, да будут оба микротика vrrp мастером, но т.к они друг про друга знать не будут, отсутствия интернета не будет. Но суть не в этом, почему при такой конфигурации не ходят другие вланы между микротиком и свичём? Может пробоема в том, что при объединении нескольких портов через свич на навешивании вланов на эту группу микротик просто не понимает толи во все порты одинаковый кадр отправить то-ли что-то еще, но при этом ничего красным не горит и ошибок нет.
попробовал создсть 2 отлельных vrrp на вторых и третьих физ.интерфейсах с переключением по скрипту. Да это частично решает проблему, но тогда не будет отрабатываться обрыв линка до конечного устройства, т.к маршрут может быть только на 1 адрес в одно время.
У меня похожая конфигурация, только коммутаторе в физическом стэке. И я в вашем случае убрал бы линк между микротиками а создал между коммутаторами, а vrrp на микротиках настраивал через этот линк Вы указали что на vrrp вешаете адрес 10.168.1.254/24, не знаю как у вас это работает, но на интерфейс VRRP можно вешать только /32, так как это псевдо интерфейс, и через него реально нечего не ходит, а ходит только через master для него. правильно ли я вас понял, что вы используете интерфейс vrrp как способ отключения петли? =), вы сказали на vrrp вешаете VLAN, а какой смысл так как VRRP это чистый L3. если вы хотите VRRP использовать в VLAN то создайте VLAN и уже на него вешайте VRRP почитайте внимательно статью http://habrahabr.ru/post/164873/ там используется способ VLAN over vrrp но с одной оговоркой, только для определения master маршрутизатора
я вот сейчас понимаю, что если бы вместо "взрослых" L3 коммутаторов я поставил туда коммутаторы микротик, можно было бы спокойно там включить vrrp и все было бы ок. Но однако по надежности они не очень. физ. стека тоже нет. Между коммутаторами был линк изначально, но в нем отпала необходимость. Т.к коммутаторы видят друг-друга через микротики. Vrrp вообще не важно что на нем висит, он просто дает вирт. мак-адрес /24 отлично работает. Я вобщем разделил бридж на 2 разных физ.интерфейса и сделал по vrrp на каждый с одинаковым адресом и на него вланы , таки да кадры пошли, но опять же есть проблемы. Очень странное поведение микротиков , если вдруг первым включился бэкап vrrp и потом сразу мастер, то интернетов не будет до тех пор, пока физически не вкл-выкл порт на котором висит vrrp. пришлось добавлять скрипты с задержкой по времени. В принципе задача резервирования решается таким образом, но все равно не ясно почему это не работает через бридж\свич, а если у нас допустим не 2 коммутатора, а 4?
Давайте взглянем на проблему под другим углом. STP/RSTP - протокол поиска петель, с возможность отключения проблемного порта в зависимости от его стоимости. VRRP- Протокол для увеличения доступности маршрутизаторов. Логично предположить что STP/RSTP используется в тех местах где коммутируются L2 сети т.е коммутаторы. VRRP используется и активируется только тогда когда, один из маршуртизаторов не доступен(помер, не работает), суть VRRP захватить IP адрес и пробросить на реальный адрес. Чтобы вы не делали в вашем случае это не VRRP, а извращение (извините), если вы хотите наладить отказоустойчивость выберите один из вариентов: STP/RSTP - только на коммутаторах и VRRP на маршрутизаторах (предпочтительнее) или STP/RSTP - на коммутаторах и маршрутизаторах, баз VRRP. Вы говорите "а если у нас допустим не 2 коммутатора, а 4?" А если 40 коммутаторов, что вы будете делать? искать маршрутизатор с 80 портами + ISP? Вы кольцо должны делать на коммутаторах и для этого существует протокол STP, а для повышения доступности маршрутизаторов существует протокол VRRP, а вы пытаетесь смешать всё в одну кучу
Также если вы отходите от RFC , где нету ни слова про сеть CIDR/netmask , не ожидайте, что у вас будет работать как должно. Вот что происходит когда вы указываете маску на VRRP интерфейсе Код: [admin@MT-0000-AP5-RKO] > /ip address pr Flags: X - disabled, I - invalid, D - dynamic # ADDRESS NETWORK INTERFACE 0 1.1.1.1/24 1.1.1.0 bridge-Local 1 1.1.1.2/24 1.1.1.0 vrrp1 Код: [admin@MT-0000-AP5-RKO] > /ip route pr Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 1.1.1.0/24 1.1.1.1 bridge-Local 0 1 DC 1.1.1.0/24 1.1.1.2 vrrp1 0 как видите второй маршрут не работает, а должно быть Код: [admin@MT-0000-AP5-RKO] > /ip route pr Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit # DST-ADDRESS PREF-SRC GATEWAY DISTANCE 0 ADC 1.1.1.0/24 1.1.1.1 bridge-Local 0 1 ADC 1.1.1.1/32 1.1.1.1 vrrp1 0
так и сделано, на микротиках vrrp, на коммутаторах mstp , изначально я пробовал просто сделать бридж из портов которые в локалку смотрят и на весить на все это дело 1 vrrp адрес, тогда не важно сколько будет коммутаторов, хоть 2, хоть 22 . Но поведение было очень странным, вроде и работает, но не всегда. С адресом, я вас не верно понял, да там можно без маски указать, но результат не меняется.
не могу вас понять, почему вы не хотите сделать так: Создаёте bridge ИЛИ swith(CPU)(что то одно) на микротике. = далее bridge вешайте на bridge необходимые vlan Приписывайте на VLAN адрес и маску Для каждого VLAN создавайте VRRP на VRRP поставьте адрес в тойже подсети что и VLAN, но и укажите \32 Так же не забудьте про приоритет на VRRP с двух сторон Также напоминаю, что адреса на VRRP интерфейсах должны быть одинаковы, если вы добавляете несколько адресов на один интерфейс VRRP то и на противоположенном интерфейсе должна быть идентичная настройка. Я могу ошибаться, но по моему MirkoTik не поддерживает mstp, можно попробовать не создавать bridge на ethernet интерфейсах, а снять с каждого интерфейса по одинаковому vlan засунуть их в bridge и настроить на бридже rstp. По идеи это и будет mstp, но необходимо тестировать.
Необходимо учитывать, что MSTP, хоть и есть на него спецификация, но каждый вендор лепит то чего сам хочет
да, работает, я почему-то на 100% был ьуверен , что нельзя на vlan вешать vrrp , видимо эта статья помешала http://silverghost.org.ua/2009/09/23/podnimaem-vrrp-na-dvux-mikrotikax/ а так да все заработало и это хорошо, спасибо. а mstp и rstp совместимы насколько я помню, да и по факту работает.
