Pull to refresh

Comments 14

В частности оба маршрутизатора умеют HSRP/VRRP которые и нужно было использовать.
HSRP/VRRP используется для резервирования gateway, резервирования именно IP адреса (Layer3). Как использовать эти протоколы для резервирования, по сути, провода идущего к маршрутизатору я ума не приложу.(Layer2).
Если Вы имеете ввиду что 3925 и 1841 страхуют друг друга по VRRP, то это не могло быть реализовано в силу условий в которых должна была работать сеть. К тому же был интерес резервировать именно подключение маршрутизатора к ядру, а не сам маршрутизатор.
Ок, я не совсем верно понял задачу.

В принципе способов наизобретать можно навалом, навскидку могу предложить EEM скрипт, который бы по состоянию интерфейса ставил на нем адрес или снимал его. Можно попробовать еще придумать через IP SLA что-нить такого плана.

Беглый гуглинг дает еще такой вариант (не шибко хороший):

If you really want to connect two router interfaces to redundant switches and have the router interfaces back each other up, then you could try configuring bridging on both router interfaces. This would allow both interfaces to be active and Spanning Tree would provide the redundancy. To be able to route traffic from the interfaces you would need to configure IRB with a BVI interface to allow IP traffic from the router interfaces to be routed.

I would not recommend this approach, but it is the way to have both interfaces on the same router back each other up.

Завтра спрошу нашего R&S-ника, возможно он попроще что-то подскажет.
У вас свичи в ядре OSPF поддерживают?
На ваш вопрос, да поддерживают. А вообще статья была написана как пример реализации протокола, и возможность резервирования на L2, все о чем вы пишите является уже L3, что уже другое, хотя и резервирование. Способы подключения Cisco 1841 и 3925 были приведены как примеры возможности сопряжения с технологией DT.
Я к тому что это не топик типа «Подскажите как организовать резерв?», извини если задел, просто переписка уходит в оффтоп.
Ни Backup interface, ни bridge group не дадут эффекта MLAG, работу обоих портов одновременно.
Первый способ отключает backup интерфейс, пока жив primary, автоматически.
Второй способ включает на обоих портах STP, так что один порт заблокируется этим протоколом.
Да, согласен. Я забыл упомянуть этот аспект, В случае с 1841 все же не удалось заставить два порта одновременно, они работают как Active/Stedbay.
Что будет, если соединить два access-свитча патчкордом?
Смотря что настроено на портах. :)
Можно сделать bpdufilter с двух сторон и поиметь в результате петлю.
Ну если ничего на свичах не настроено, то получим классическую петлю из трех свичей, 2 access + 1 логический core. Против петель есть же не только STP, к примеру можно включить Loop Protection, который отключит закольцованный порт.
Но какой смысл в отключении STP, если LAG в нём воспринимается как единое целое и скорость не ограничивается одним портом?
Можно и не отключать, я привел loop protection как альтернативу STP при контроле петель… тут уж как кому удобнее/практичние. Бывают ситуации когда механизм работы STP не вписывается в работу сети, легче прогнать пару флудовых пакетов в одном сегменте сети, и отключить порт по loop protection, чем спровоцировать всю сеть на переконвергирование по STP.
Sign up to leave a comment.

Articles