PBR- Policy Based Routing (Cisco) Делим траффик пополам
Здравствуйте, дорогие читатели! Сегодня мы рассмотрим policy-based routing (маршрутизацию на основе политик) и его практическое применение в лабораторной работе с использованием GNS3. Вся информация будет представлена на практике. Вот наша топология, с которой мы будем работать. Маршрутизация будет осуществляться с помощью протокола OSPF.
Наша топология
Вот базовая настройка роутеров
Если HR или Me отправляют IP-пакет на SRV, то пакет пройдет через роутер 2, так как у него более низкая метрика. OSPF подсчитает топологию и метрику, и, учитывая это, пакет будет направлен через второй роутер. На серийном линке я настроил энкапсуляцию PPP. Для нас сейчас не так важны детали работы PPP на серийных линках, такие как скорость, особенности OSPF и другие параметры важно понять суть
Для начала убедимся что траффик идет через роутер 2
Как мы знаем, в OSPF можно гибко управлять метрикой и настроить маршруты так, чтобы пакеты шли через серийный линк к следующему хопу — роутеру R1.
А что если мы хотим, чтобы трафик «балансировался»: один проходил через серийный линк, а другой — через Fast Ethernet? С помощью метрики в OSPF мы это не можем настроить, потому что метрика определяет лучший путь для всего трафика, а нам нужен механизм, который будет учитывать конкретный источник или назначение IP-адреса для выбора next-hop.
Почему это может быть полезно? Например, в нашей топологии голосовой трафик может идти через серийный линк, а пользовательский трафик — через Fast Ethernet. Это можно реализовать с помощью Policy-Based Routing (PBR). На роутере 3 будет настроен route map, который будет проверять IP-адрес источника пакета. Если в качестве источника указан IP-адрес 192.168.1.2, пакет будет направляться через 10.0.1.1. Если же источник будет другим, трафик пойдет через сериал линк на 10.0.2.1
И так перейдем к настройке роутера 3
В этом процессе мы создаем набор правил, который позволяет динамически управлять маршрутизацией трафика в зависимости от его источника (или других критериев). Policy-based Routing (PBR) помогает обеспечить гибкость в маршрутизации трафика, обеспечивая при этом оптимальную работу различных сервисов в сети, например, выделяя определенные каналы для голосового трафика или трафика пользователей.
В конфигурации указано, что для IP-адреса 192.168.1.3 трафик будет направляться через GigabitEthernet4/0 с IP-адресом 192.168.1.1.
Сначала на маршрутизаторе создается ACL (Access Control List) с именем CTRL-ACL, который разрешает трафик от IP 192.168.1.3. Затем, через route-map применяется настройка, что при совпадении IP-адреса с ACL, трафик будет направляться на next-hop 10.0.2.1.
В конечном итоге на интерфейсе GigabitEthernet4/0 применяется route-map, который управляет маршрутизацией трафика через заданный next-hop.
Для проверки правильности работы, выполним трассировку траффика на пк
При настройке роут-мэп на маршрутизаторе, он не обращает внимания на таблицу маршрутизации, а сразу направляет трафик через next-hop, указанный в роут-мэп. Этот механизм позволяет игнорировать все другие правила, что дает гибкость в управлении маршрутизацией. Однако если роут-мэп не настроен для другого IP-адреса источника, то трафик будет обрабатываться по таблице маршрутизации, как обычно. В нашем случае в таблице маршрутизации указано, что весь трафик должен направляться через next-hop 10.0.1.2.
Таким образом, если IP-адрес источника совпадает с условием роут-мэпа, маршрутизатор будет следовать правилам роут-мэпа, а если нет — трафик будет направляться согласно стандартным маршрутам в таблице. Это позволяет значительно улучшить управление трафиком, предоставляя возможность задавать индивидуальные правила маршрутизации для разных источников и типов трафика.
На картинке видно, как работает Policy-BasedRouting (PBR). Мы видим, что на роутере R3 в логах показывается, что некоторые пакеты проходят через нормальную маршрутизацию (в которых не сработал PBR), а другие проходят через указанный next-hop (для которых сработала политика).
видно два типа сообщений:
FIB policy rejected (no match) — Пакеты, которые не совпали с условиями PBR и пошли по обычной маршрутизации.
FIB policy routed — Пакеты, которые прошли через маршрутизацию на основе политики (PBR) и пошли через заданный next-hop.
Другие команды диагностики
На скриншоте показана диагностика конфигурации Policy-Based Routing (PBR) на маршрутизаторе R3.
Команда show ip policy подтверждает, что на интерфейсе GigabitEthernet4/0 применяется route-map с названием CONTROL-RM. В выводе команды show route-map видим, что в route-map есть:
Match clause: используется ACL под названием CTRL-ACL, который фильтрует пакеты по заданным критериям.
Set clause: для подходящих пакетов установлен next-hop на адрес 10.0.2.1, что означает, что трафик будет направляться через этот адрес.
Также видно, что next-hop tracking сейчас показывает 0.0.0.0, что может означать отсутствие активных изменений в маршрутах на данный момент.
В конце выводится информация, что policy routing сработал для 37 пакетов и 3842 байт трафика.
Это подтверждает, что PBR работает, и трафик, соответствующий правилам, отправляется через нужный next-hop.
Policy-Based Routing (PBR) — это очень гибкий инструмент, который позволяет настраивать маршрутизацию с учетом различных условий. Например, можно настроить так, чтобы TCP-пакеты отправлялись через серийный линк, а UDP-пакеты — по обычному маршруту, используя таблицу маршрутизации. В таком случае достаточно изменить ACL с командой permit udp any any, чтобы разрешить все UDP-пакеты.
Можно комбинировать эти правила для различных типов трафика или настроить маршрутизацию только для TCP, UDP и других типов трафика. Для этого необходимо знать, как правильно работать с ACL, чтобы настроить нужные фильтры.
Спасибо за внимание! Всем, кто прочитал, буду рад вашим комментариям и рассуждениям.
© Javid CCNP
