Привлекательность заключается в возможности использовать пересекающиеся адресные пространства, управляемые одним маршрутизатором, и/или настраивать индивидуальную маршрутизацию для разных клиентов проще, чем использовать весь набор настроек policy routing. Ограничим пример маршрутизацией внутри пересекающихся адресных пространств. Представьте четыре сети — A, B, C и D. A и B используют одинаковые подсети, как и C и D. На вашем маршрутизаторе для подключения каждой из четырёх сетей используется по одному интерфейсу, которому назначен IP из соответствующей подсети. Таким образом, система динамически создаёт маршруты к этим подключённым подсетям и выбирает между ними непредсказуемым образом (это не случайно, просто непредсказуемо — всегда будет выбран один из идентичных маршрутов в каждой паре, но заранее узнать какой — нельзя).
Ваша задача — сделать так, чтобы пакет из сети A с адресом назначения, совпадающим и с C, и с D, всегда шел в сеть C, а пакет из сети B по тому же адресу назначения — всегда в D. При «ручной» policy routing вам нужно создать правила mangle, чтобы назначить пометку маршрутизации «AC» пакетам, приходящим через интерфейсы, подключённые к сетям A и C, и пометку «BD» — пакетам с интерфейсов сетей B и D. Далее приходится вручную создавать маршруты в подсети A и C с меткой AC и маршруты в подсети B и D с меткой BD, чтобы переопределить динамически создаваемые маршруты, как описано выше.
В итоге, когда пакет к адресу «C или D» приходит через интерфейс A, ему присваивается метка маршрутизации AC, и становится действительным только маршрут к C, хотя динамически сгенерированный маршрут к D с тем же адресом существует. Аналогично, пакет к «C или D» через интерфейс B получает метку BD, и становится применим только маршрут с меткой BD к D. Если же один из интерфейсов откажет, соответствующий тематический маршрут становится недоступен, и маршрутизация падает на динамически созданный маршрут без метки, из-за чего пакет может попасть не в ту сеть.
Чтобы этого избежать, надо использовать два правила маршрутизации /ip route с параметром routing-mark=X action=lookup-only-in-table table=X (одно с X=AC, другое с X=BD).
Всего получается:
- два правила mangle, ссылающихся на два списка интерфейсов по два интерфейса в каждом,
- четыре маршрута с метками,
- два правила маршрутизации.
Используя настройку vrf, достаточно двух конфигурационных записей для определения двух виртуальных маршрутизирующих экземпляров:
/ip route vrf add interfaces=A,C routing-mark=AC
/ip route vrf add interfaces=B,D routing-mark=BD
Это гарантирует, что:
- динамически создаваемые маршруты к подключённым подсетям A,B,C,D будут (пере)создаваться с метками маршрутизации AC и BD соответственно, а не в основной таблице маршрутизации (то есть не нужно вручную создавать маршруты и использовать правила маршрутизации, чтобы предотвратить возврат к одинаковым маршрутам из основной таблицы при отказе интерфейса);
- пакеты, входящие через интерфейсы A, B, C, D, автоматически получают соответствующую метку маршрутизации, без создания правил mangle.
Таким образом, настройка становится намного проще и аккуратнее, если использовать vrf в некоторых сценариях. Но есть ограничения — те же таблицы маршрутизации и метки используются и для vrf, и для обычного policy routing, так что если вы захотите одновременно применять обычный policy routing с настройкой vrf, можете быстро запутаться в их взаимозависимостях.
Ещё одна возможность, не входящая в пример выше, как упоминалось в предыдущих сообщениях — обновление каждой таблицы маршрутизации, созданной vrf, независимо, с помощью отдельного экземпляра динамического протокола маршрутизации.
