<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
	<channel>
		<title>Mikrotik.moscow [тема: Вопрос по конфигурации VRRP.]</title>
		<link>http://mikrotik.moscow</link>
		<description>Новое в теме Вопрос по конфигурации VRRP. форума RouterOS на сайте Mikrotik.moscow [mikrotik.moscow]</description>
		<language>ru</language>
		<docs>http://backend.userland.com/rss2</docs>
		<pubDate>Tue, 18 Aug 2026 12:39:49 -0400</pubDate>
		<item>
			<title>Вопрос по конфигурации VRRP.</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256656">Вопрос по конфигурации VRRP.</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Я полностью согласен! (Конечно… Если говорить об этой теме, которую я начал, то можно выделить 2 основные области для улучшения в MT VRRP: “VR-ассоциации” между интерфейсами. Мы могли бы зарезервировать ethernet-порт на каждом устройстве для соединения кроссовером: когда heartbeat отсутствует, можно предположить, что другое устройство вышло из строя (обычно кроссоверы не умирают). В этой ситуации ВСЕ адреса должны переходить на выжившую резервную коробку, так что единственным "не виртуальным" адресом будет пара на ethernet-порту, зарезервированном для heartbeat. Heartbeat также можно разделить с трафиком (как в доверенной локальной сети, используя дополнительные выделенные адреса). Обновление конфигурации между VRRP-коробками. С вышеуказанным шагом консистентность конфигурации между VRRP-узлами становится чрезвычайно важной. В сложной среде часто очень трудно отслеживать каждое изменение на основном узле и немедленно реплицировать его на подчиненных, поэтому, по моему мнению, простой и надежный механизм репликации конфигурации был бы ключевым отличием MT как от бесплатных (Linux), так и от коммерческих решений. К сожалению, насколько я знаю, инструменты, доступные "из коробки", не подходят для этой цели: файлы резервного копирования/восстановления создают подчиненный узел "слишком идентичным" основному, потому что он также клонирует элементы конфигурации, которые должны оставаться уникальными: все MAC-адреса, heartbeat IP, VRRP-конфигурация, имена идентификаторов и так далее… Я пробовал с комбинацией restore+script, где скрипт персонализирует резервную копию сразу после восстановления… но этот подход не поддерживается Mikrotik. Экспорт/Импорт слишком далек от автоматизированного скрипта, чтобы его можно было применить к устройству, сброшенному до заводских настроек, чтобы преобразовать его в VRRP-резервный узел. В основном основная проблема заключается в том, что команда Export не записывает элементы конфигурации в последовательность, которую можно использовать "как есть" командой Import. Поэтому ручная задача по переупорядочению команд и удалению тех, которые необходимо сохранить уникальными, делает этот способ довольно неэффективным. Любая помощь была бы очень кстати.<br /><br />Riccardo <br />
			<i>26.04.2006 08:31:00, rileonar.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256656</link>
			<guid>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256656</guid>
			<pubDate>Wed, 26 Apr 2006 08:31:00 -0400</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Вопрос по конфигурации VRRP.</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256655">Вопрос по конфигурации VRRP.</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Поднимаю тему снова… кто-нибудь? В текущем виде VRRP реально поможет нам, использующим эту штуковина как файрвол, только в случае полного выхода из строя. Если я просто потерял интерфейс, это мне ничего не дает, потому что интерфейс на другой стороне FW не знает, что нужно отключаться. Есть ли какой-нибудь способ сделать это без скриптовых костылей? Или можно попросить ребят из MT добавить VRRP-ассоциацию в будущую версию? Это бы вообще решило проблему. Ну кто-нибудь, хоть кто-нибудь? Я правда не хочу покупать Pix для нормального отказоустойчивого режима. Спасибо, Jerm. <br />
			<i>26.04.2006 04:25:00, jerm.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256655</link>
			<guid>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256655</guid>
			<pubDate>Wed, 26 Apr 2006 04:25:00 -0400</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Вопрос по конфигурации VRRP.</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256654">Вопрос по конфигурации VRRP.</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Интересно узнать и я. Пытался настроить VRRP + BGP в 2.8, не получилось, поэтому использовал только BGP. Это как-то улучшится в 2.9.19? И если да, то интерфейсы, общающиеся с BGP-пирами, тоже должны быть в VRRP? Возможно ли это сделать? <br />
			<i>09.04.2006 04:18:00, nikhil.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256654</link>
			<guid>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256654</guid>
			<pubDate>Sun, 09 Apr 2006 04:18:00 -0400</pubDate>
			<category>RouterOS</category>
		</item>
		<item>
			<title>Вопрос по конфигурации VRRP.</title>
			<description><![CDATA[<b><a href="http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256653">Вопрос по конфигурации VRRP.</a></b> <i>RouterOS</i> в форуме <a href="http://mikrotik.moscow/forum/forum57/">RouterOS</a>. <br />
			Привет, мне нужно настроить VRRP на паре MT, у каждого из которых по 4 интерфейса. Конфигурация одного vr group не позволяет перенести несколько адресов на разные интерфейсы (хотя это очевидно необходимо для корректной работы роутера с 4 интерфейсами: внешний, внутренний, DMZ1 и DMZ2). Так что единственное решение, кажется, создать 4 vr group, по одной на каждый интерфейс. Этот подход, однако, должен создать много независимых vr engine, каждый со своим heartbeat траффиком и так далее… Кто-нибудь знает, есть ли другой (возможно, более чистый и эффективный) способ сделать эту работу? В другом посте я читал про использование скриптов для ручного включения/выключения адресов при событиях master-backup, но это кажется довольно ненадежным… Я думаю, это довольно распространенная ситуация, поэтому любые предложения будут очень признательны. Заранее большое спасибо. С уважением, Риккардо <br />
			<i>22.02.2006 09:56:00, rileonar.</i>]]></description>
			<link>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256653</link>
			<guid>http://mikrotik.moscow/forum/forum57/66093-vopros-po-konfiguratsii-vrrp./message256653</guid>
			<pubDate>Wed, 22 Feb 2006 09:56:00 -0500</pubDate>
			<category>RouterOS</category>
		</item>
	</channel>
</rss>
