Juniper настройка FBF (PBR), routing-instance type forwarding and virtual-router

Больше
1 год 5 мес. назад - 1 год 5 мес. назад #250 от PNV
COM_KUNENA_MESSAGE_CREATED_NEW
В данной теме описана процедура настройки Filter Based Forwarding (FBF), или как привычнее это звучит в терминологии Cisco - PBR (Policy Based Routing), а также типы routing-instance на оборудовании Juniper: type forwarding и type virtual-router.
Настройка будет осуществляться на коммутаторе Juniper EX-4200.
По ходу описания я буду по возможности сопоставлять термины Juniper c терминами Cisco, для тех кто привык работать с Cisco.


Начнём пожалуй с описания routing-instance type virtual-router.
Данный тип routing-instance в Juniper очень похож на vrf-lite в Cisco. Virtual-router необходим для изоляции таблицы маршрутизации и L3-интерфейсов в конкретной routing-instance от других таблиц и интерфейсов в системе. В данной routing-instance можно описывать различные типы интерфейсов и протоколов маршрутизации, а также под неё создаётся своя отдельная таблица маршрутизации Name_of_routing_instance.inet.0. В ней нет необходимости указания route-distinguisher, vrf-import, and vrf-export, как для VRF, т.к. никакие ID не нужно отправлять за пределы устройства. Т.е. по сути это отдельный виртуальный L3-коммутатор (если рассматривать на примере EX-4200). Таким образом данный тип routing-instance используется например у провайдера для изоляции разных клиентских таблиц маршрутизации между собой, а также например в рамках одной компании для разделения трафика на различные зоны типа DMZ и Intranet и т.п.

Далее пример настройки routing-instances type virtual-router:

ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]

Теперь посмотрим таблицу маршрутизации для routing-instance VR-TEST:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]

Таким образом мы создали routing-instance с отдельными интерфейсами, протоколами маршрутизации и отдельной таблицей маршрутов. Чуть ниже в данной теме будет описание про экспорт и импорт маршрутов из одной таблицы маршрутизации в другую (из одной Instance в другую instance).


Routing-instance type forwarding
- предназначен для Filter Based Forwarding (FBF), т.е. в переводе на Cisco - PBR (Policy Based Routing). Так например, если на оборудование Cisco для создания политик маршрутизации и перенаправления трафика используются route-map и access-list, то на Juniper это делается при помощи routing-instance, rib-group и filter. Также данный тип routing-instance, помимо FBF, используется например для переброски трафика из одной routing-instance в другую. Данный тип routing-instance не содержит в себе описание интерфейсов и протоколов маршрутизации, она нужна лишь для перенаправления трафика по заданным в соответствии с политикой маршрутам. При этом для данной routing-instance создается своя отдельная таблица маршрутизации в которую импортируются маршруты из так называмого primary route table. В качестве primary route table может выступать как глобальная таблица маршрутизации inet.0, так и таблица маршрутизации какого-либо другого routing-instance, например из предыдущего примера VR-TEST.inet.0.

Рассмотрим пример создания routing-instance type forwarding и написания FBF, используя предыдущий пример с routing-instance type virtual-router VR-TEST. Задача: перенаправить трафик с хоста 10.12.22.50 (интерфейс vlan.1322) до сети 10.14.11.0/24 по статическому маршруту через next-hop 10.254.10.18.
10.14.11.0/24      *[OSPF/110] 4d 05:29:47, metric 12
                    > to 10.254.12.42 via vlan.1231
(как видно из таблицы, сейчас маршрут до сети 10.14.11.0/24 приходит по OSPF через другой next-hop - 10.254.12.42).

И так, создадим для начала routing-instance type forwarding с именем VF и пропишем в ней статический маршрут:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]

Далее создадим RIB-группу VF, которая будет связывать таблицу маршрутов и интерфейсы primary routing-instance VR-TEST и routing-instance VF, и импортируем в неё direct (connected в терминологии Cisco) маршруты и ospf-маршруты из routing-instance VR-TEST:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


С таблицами маршрутизации и routing-instance закончили, теперь собственно создадим само правило, по которому трафик с хоста 10.12.22.50 (с интерфейса vlan.1322) в сеть 10.14.11.0/24 будет идти через 10.254.10.18:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]

В конце не забываем правило по умолчанию Default для всего остального трафика, который идёт в соответствии с таблицей маршрутизации своего routing-instance.

Применим созданное правило на соответствующий L3-интерфейс:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]


На этом конфиг готов.
Применяем конфиг и смотрим таблицу маршрутизации для instance VF:
ВНИМАНИЕ: Спойлер! [ Нажмите, чтобы развернуть ]

и видим, что в таблице присутствует статический маршрут до сети 10.14.11.0/24.
Также мы видим, что в данной таблице отсутствует статический маршрут, который присутствует в VR-TEST.inet.0:
user@EX-4200# run show route table VR-TEST.inet.0

VR-TEST.inet.0: 8 destinations, 8 routes (8 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

10.14.11.0/24      *[OSPF/110] 4d 05:29:47, metric 12
                    > to 10.254.12.42 via vlan.1231
здесь нет ошибки, т.к. мы импортировали из routing-instance VR-TEST в routing-instance VF только direct и OSPF-мршруты.
Last edit: 1 год 5 мес. назад by PNV.

Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.

Работает на Kunena форум