Почему классической маршрутизации недостаточно
Классическая маршрутизация принимает решение о передаче пакета, анализируя только IP-адрес назначения. Маршрутизатор заглядывает в таблицу маршрутизации, находит наиболее специфичный префикс и отправляет пакет в соответствующий интерфейс или на next-hop. Эта модель проста, предсказуема и отлично работает в сетях, где весь трафик равнозначен. Проблемы начинаются, когда появляются разнородные потоки данных с разными требованиями к задержкам, пропускной способности и безопасности.
Представьте: голосовой трафик VoIP идет через тот же перегруженный интернет-канал, что и резервное копирование баз данных. Результат - дробление голоса, жалобы пользователей и невозможность гарантировать качество. Или другой случай: регулятор требует, чтобы трафик от серверов финансового аудита уходил строго через выделенный канал с логированием, но обычная маршрутизация отправляет его в общий поток. В обоих сценариях классический подход бессилен - он не различает природу трафика.
Policy-Based Routing (PBR) решает эти задачи, добавляя гибкость. PBR позволяет маршрутизатору анализировать не только адрес назначения, но и множество других критериев: порт источника или назначения, протокол, значение DSCP, длину пакета, адрес источника. Вы получаете инструмент, который направляет трафик по нужному пути в зависимости от бизнес-логики, требований QoS или политик безопасности.
Как работает Policy-Based Routing: ключевые концепции
PBR обрабатывает пакеты до обращения к обычной таблице маршрутизации. Когда пакет поступает на интерфейс, на котором активирована политика, маршрутизатор проверяет его на соответствие заданным критериям. Если пакет совпадает с условием, применяется действие - например, отправка на конкретный next-hop или выходной интерфейс. Если совпадений нет, пакет передается стандартной маршрутизации.
Ключевые компоненты PBR: route-map, условия match и действия set. Route-map объединяет логику, условия определяют, какой трафик обрабатывать, а действия задают, что с ним делать. PBR может применяться на входящем интерфейсе или локально - для трафика, генерируемого самим маршрутизатором.
Route-map: сердце PBR
Route-map - это последовательность правил, каждое из которых имеет номер (sequence number) и действие permit или deny. Маршрутизатор обрабатывает правила в порядке возрастания номеров. При первом совпадении с условием match выполняется соответствующее действие set, и обработка прекращается.
Если правило помечено как deny и пакет совпал с условием, он не обрабатывается PBR и возвращается к обычной маршрутизации. Это полезно для исключения определенного трафика из политики. Если ни одно правило не совпало, пакет также идет через стандартную таблицу маршрутизации. Простейший пример route-map:
route-map PBR-POLICY permit 10
match ip address ACL-VOIP
set ip next-hop 192.168.10.1Здесь правило с номером 10 проверяет, совпадает ли пакет с ACL-VOIP, и при совпадении отправляет его на шлюз 192.168.10.1.
Критерии отбора трафика: от ACL до DSCP
Гибкость PBR обеспечивается разнообразием условий match. Основные критерии:
- Standard и Extended ACL - фильтрация по адресам источника и назначения, портам и протоколам. Extended ACL позволяет точно выделить трафик конкретного приложения, например, HTTPS-запросы от определенной подсети.
- DSCP и ToS - маркировка пакетов, используемая для QoS. Трафик VoIP часто помечается значением DSCP EF (46), что позволяет PBR направить его по приоритетному каналу.
- Длина пакета - специфичный критерий для выделения пакетов определенного размера, например, управляющих сообщений малой длины.
Пример match для VoIP-трафика по DSCP:
ip access-list extended ACL-VOIP-DSCP
permit ip any any dscp ef
!
route-map PBR-VOIP permit 10
match ip address ACL-VOIP-DSCP
set ip next-hop 10.0.0.1Пример match для аудиторского трафика по подсети источника:
ip access-list standard ACL-AUDIT-SUBNET
permit 172.16.100.0 0.0.0.255
!
route-map PBR-AUDIT permit 10
match ip address ACL-AUDIT-SUBNET
set ip next-hop 192.168.200.1Практические сценарии внедрения PBR
Переходим к готовым рецептам. Каждый кейс - это проверенная конфигурация для конкретной задачи. Вы можете адаптировать параметры под свою среду.
Гарантированная доставка VoIP: приоритет через выделенный канал
Голосовой трафик критичен к задержкам и джиттеру. Обычный интернет-канал, загруженный скачиванием обновлений или резервным копированием, неизбежно ухудшит качество связи. Решение - направить VoIP через выделенный MPLS-линк или качественный интернет-канал с гарантированным SLA.
Конфигурация на интерфейсе LAN, куда подключены IP-телефоны:
! ACL для голосовых подсетей
ip access-list extended ACL-VOIP-TRAFFIC
permit ip 10.1.10.0 0.0.0.255 any
permit ip 10.1.20.0 0.0.0.255 any
!
! Route-map
route-map PBR-VOIP-PRIORITY permit 10
match ip address ACL-VOIP-TRAFFIC
set ip next-hop 203.0.113.1
!
! Применение на интерфейсе
interface GigabitEthernet0/1
ip policy route-map PBR-VOIP-PRIORITYПроверка работы:
show route-map PBR-VOIP-PRIORITY
show ip policyКоманда show route-map отобразит счетчики совпадений, что позволяет убедиться, что политика действительно обрабатывает трафик.
Выделенный канал для аудита: соответствие регуляторным требованиям
Финансовые организации и компании, работающие с персональными данными, обязаны обеспечить изоляцию аудиторского трафика. Регуляторы требуют, чтобы логи и данные аудита передавались через защищенный канал с полным логированием. PBR решает эту задачу, направляя трафик от серверов аудита на выделенный шлюз.
Конфигурация:
! ACL для серверов аудита
ip access-list standard ACL-AUDIT-SERVERS
permit 192.168.50.10
permit 192.168.50.11
!
! Route-map
route-map PBR-AUDIT-CHANNEL permit 10
match ip address ACL-AUDIT-SERVERS
set ip next-hop 198.51.100.1
!
! Применение на интерфейсе, куда подключены серверы
interface GigabitEthernet0/2
ip policy route-map PBR-AUDIT-CHANNELКритическое предупреждение: PBR влияет только на исходящий трафик. Обратный трафик от внешних систем к серверам аудита должен возвращаться тем же путем, иначе возникнет асимметричная маршрутизация. Решение - настройка симметричной маршрутизации на стороне провайдера выделенного канала или использование source NAT на граничном маршрутизаторе, чтобы ответный трафик гарантированно шел через тот же канал. Подробнее эта проблема и способы ее решения разобраны в руководстве по асимметричной маршрутизации.
Балансировка между несколькими интернет-каналами
Компании с двумя и более интернет-провайдерами могут использовать PBR для распределения нагрузки и повышения отказоустойчивости. Типичный сценарий: гостевой Wi-Fi направляется через недорогой резервный канал, критичный бизнес-трафик - через основной, а при падении одного канала весь трафик автоматически переключается на оставшийся.
Конфигурация с отслеживанием доступности через IP SLA:
! Отслеживание доступности основного шлюза
ip sla 1
icmp-echo 203.0.113.1 source-interface GigabitEthernet0/0
frequency 10
ip sla schedule 1 life forever start-time now
!
track 1 ip sla 1 reachability
!
! ACL для гостевого Wi-Fi
ip access-list standard ACL-GUEST-WIFI
permit 172.16.200.0 0.0.0.255
!
! Основная политика: гостевой трафик через резервный канал
route-map PBR-DUAL-WAN permit 10
match ip address ACL-GUEST-WIFI
set ip next-hop verify-availability 198.51.100.1 10 track 1
set ip next-hop 203.0.113.1
!
! Применение
interface GigabitEthernet0/1
ip policy route-map PBR-DUAL-WANЛогика работы: гостевой трафик направляется на резервный шлюз 198.51.100.1. Если основной шлюз 203.0.113.1 недоступен (track 1 падает), PBR переключает гостевой трафик на основной канал, чтобы сохранить связность. Бизнес-трафик, не попавший в ACL, идет через стандартную маршрутизацию, где также можно настроить резервирование через протоколы динамической маршрутизации. Детали настройки отказоустойчивых шлюзов описаны в руководстве по BGP и OSPF.
Направление трафика через цепочки security-инспекции
Современные политики безопасности требуют глубокого анализа трафика перед его выходом в интернет. PBR позволяет направить потоки из определенных VLAN через межсетевой экран следующего поколения (NGFW) или систему предотвращения вторжений (IPS), даже если эти устройства не являются шлюзом по умолчанию.
Конфигурация:
! ACL для трафика, требующего инспекции
ip access-list extended ACL-SECURITY-INSPECTION
permit ip 10.0.10.0 0.0.0.255 any
permit ip 10.0.20.0 0.0.0.255 any
!
! Route-map, направляющий трафик на внутренний интерфейс NGFW
route-map PBR-TO-NGFW permit 10
match ip address ACL-SECURITY-INSPECTION
set ip next-hop 192.168.1.100
!
! Применение на LAN-интерфейсе маршрутизатора
interface GigabitEthernet0/1
ip policy route-map PBR-TO-NGFWВажный момент: NGFW должен иметь маршрут для обратного трафика обратно на маршрутизатор, а не напрямую в интернет. Политики на файрволе должны разрешать такой транзит. Этот подход создает прозрачную для пользователей цепочку инспекции, сохраняя централизованный контроль над безопасностью. Для изоляции трафика отдельных приложений и контейнеров через VPN с использованием аналогичного подхода в Linux, смотрите руководство по PBR в Linux для Docker и VPN.
Рекомендации по внедрению и типичные ошибки
Внедрение PBR требует учета нескольких факторов, которые напрямую влияют на стабильность и производительность сети. Разберем основные проблемы и способы их избежать.
Влияние на производительность и способы минимизации
Существует миф, что PBR всегда снижает производительность маршрутизатора. Это верно только для устаревших платформ, где PBR обрабатывался через process switching - каждый пакет отправлялся на CPU. Современные платформы Cisco поддерживают PBR в CEF (Cisco Express Forwarding), что означает обработку политик на аппаратном уровне без значительного влияния на производительность.
Тем не менее, чрезмерное количество правил и сложные ACL с тысячами записей создают нагрузку на TCAM-память и CPU при обновлении политик. Рекомендации:
- Минимизируйте число route-map, объединяя правила там, где это возможно.
- Используйте агрегированные ACL вместо множества отдельных записей - один префикс /22 вместо четырех /24.
- Тестируйте политики в лабораторной среде перед развертыванием в production, измеряя загрузку CPU до и после применения PBR.
Отладка и верификация политик
После применения PBR необходимо убедиться, что трафик идет по заданному пути. Основные инструменты диагностики:
show ip policy- показывает, на каких интерфейсах активирована PBR и какая route-map привязана.show route-map [имя]- отображает статистику совпадений по каждому правилу. Если счетчик не увеличивается, трафик не попадает под условия match.traceroute [адрес] source [интерфейс]- позволяет проверить реальный путь пакета от указанного источника.debug ip policy- детальный лог обработки пакетов политикой. Используйте с осторожностью в production из-за высокой нагрузки на CPU.
Типичные ошибки при внедрении:
- Забытый обратный трафик. PBR управляет только исходящим направлением. Если ответный трафик пойдет другим путем, соединение нарушится. Всегда проверяйте маршрутизацию в обоих направлениях.
- Слишком сложные route-map. Множество вложенных условий затрудняют отладку. Документируйте каждое правило с указанием его назначения.
- Отсутствие мониторинга. Без IP SLA и track политика не узнает о падении next-hop и продолжит отправлять трафик в недоступный канал. Настройте отслеживание для всех критичных путей.
- Применение PBR на неправильном интерфейсе. Политика обрабатывает входящий трафик на интерфейсе. Если вы хотите управлять трафиком от серверов, PBR должна быть на интерфейсе, куда эти серверы подключены, а не на выходном WAN-интерфейсе.
Для специалистов, работающих в гетерогенных средах, доступны отдельные руководства по настройке PBR в других операционных системах: настройка PBR в Windows Server 2026 и политики маршрутизации для корпоративных VPN с готовыми конфигурациями для Palo Alto и Fortinet.