Policy-based Routing (PBR), пример конфигурации

На картинке представлена виртуальная схема офиса. Состоит она из 3-х маршрутизаторов, коммутатора, 2-х серверов и символического клиента, который в единственном лице представляет пользовательские ПК: 
1. Маршрутизатор нашего офиса (R1).
2. Маршрутизатор провайдера основного (ISP1).
3. Маршрутизатор резервного провайдера (ISP2).
4. Почтовый сервер (mail)
5. Прокси-сервер (proxy)
6. Коммутатор (ws1)
7. Клиент (PC)

Так же, на схеме не отображен удаленный офис, но в статье он будет подразумеваться.

Есть у нас сеть пользователей, 192.168.0.0/27 им нужны сервисы такие как, внутренняя почта, интернет, и другие которые в нашей схеме не зафиксированы. Сервера будут жить у нас в сети 192.168.0.32/29 (на схеме отражены 2 сервера, сервер внутренней почты, и proxy-сервер). Ну и внешние сети. Итого получим следующий адресный план.

Исходные данные, мы отобразили теперь перейдем к конфигурации оборудования, вначале я настрою оборудование офиса виртуального, как говориться «что бы работало». При переносе исходных данных в конфигурацию мы получаем, вот такое:

R1#sh run | b int
interface Tunnel1
description ### tunnel over ISP1 ###
ip address 192.168.1.1 255.255.255.252
tunnel source 10.1.1.2
tunnel destination 10.0.0.2
!
interface Tunnel2
description ### tunnel over ISP2 ###
ip address 192.168.2.1 255.255.255.252
tunnel source 10.2.2.2
tunnel destination 10.0.0.2
!
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0/0.10
description ### client network ###
encapsulation dot1Q 10
ip address 192.168.0.1 255.255.255.224
!
interface GigabitEthernet0/0.20
description ### servers network ###
encapsulation dot1Q 20
ip address 192.168.0.33 255.255.255.224
!
interface GigabitEthernet0/0.30
description ### proxy out int ####
encapsulation dot1Q 30
ip address 192.168.0.65 255.255.255.252
!
interface GigabitEthernet0/1
no ip address
duplex auto
speed auto
!
interface GigabitEthernet0/1.40
description ### ISP1 p-to-p ###
encapsulation dot1Q 40
ip address 10.1.1.2 255.255.255.252
!
interface GigabitEthernet0/1.50
description ### ISP2 p-to-p ###
encapsulation dot1Q 50
ip address 10.2.2.2 255.255.255.252
Конфигурацию Коммутатора ws1, я приводить не буду. Поверим на слово что все порты в своих вланах, порты, в mode trunk, пропускают только нужные вланы. Аналогично можно сказать про сервера, они настроены и корректно отрабатывают свою задачу.

Ситуация когда нужна просто гибкая маршрутизация.

Итак вот у нас есть виртуальный офис, и хотим мы контролировать пользователей, считать трафик и т.п. для этого у нас есть proxy сервер(далее просто proxy), следовательно нам нужно завернуть трафик от пользовательской сети, на proxy. Задача есть, приступаем к решению.
Для начала нужно выбрать сеть для которой мы будем «рисовать» карту маршрутизации.
Это можно делать 2-мя способами через ACL, или метить (применять) трафик, который проходит через логический интерфейс, направляем на porxy.  делаем карту либо так:

access-list 101 permit ip 192.168.0.0 0.0.0.31 any
!
route-map client permit 5
match ip address 101
set ip next-hop 192.168.0.35

либо так:
route-map clientif permit 5
match interface GigabitEthernet0/0.10
set ip next-hop 192.168.0.35
Что мы получаем в итоге. Весь клиентский трафик пойдет у нас на proxy, и дальше proxy уже будет думать советуясь со своей таблицей маршрутизации куда трафик отправить. При такой картине, у нас появляется маленький нюанс. Клиенты (MUA), обращаются к почтовому серверу (MTA), через лишний хоп (proxy), а это уже возможная лишняя проблема предоставления услуг, в частности потового сервиса. Ведь администраторы proxy, могут не только к примеру перегружать сервер, но и вывести из строя работоспособные настройки, да и банальная поломка железа на сервере, а вас как назло нет на месте и нет доступа к роутеру. В общем не совсем корректно, тут лучше обойти этот лишний хоп. Делается это тоже несколькими способами:

1. Способ это — прописать вместо ip next-hop, ip default next-hop. Тем самым карта не будет отрабатывать для mail, так как, он у нас находится в глобальной таблице маршрутизации в сети которая directly connection.

2. Способ переписать наш акцесс лист 
access-list 101 deny ip 192.168.0.0 0.0.0.31 host 192.168.0.34
access-list 101 permit ip 192.168.0.0 0.0.0.31 any
Естественно, тут можно модифицировать, к примеру, что бы у нас обращение клиентов к серверам шло напрямую без участия proxy, тогда вместо:
access-list 101 deny ip 192.168.0.0 0.0.0.31 host 192.168.0.34
пишем
access-list 101 deny ip 192.168.0.0 0.0.0.31 192.168.0.34 0.0.0.31

Или нарисовать карту с портами. Т.е. к примеру вы хотите контролировать доступ по RDP, на proxy, но клиенты по почтовым портам ходили на прямую, то рисуем так листы:

access-list 101 deny tcp 192.168.0.0 0.0.0.31 host 192.168.0.34 eq smtp
access-list 101 permit ip 192.168.0.0 0.0.0.31 any

про ip locacl policy.

И так у нас 2 провайдера. Для начала настроим общение нашего роутера с провайдерами. Перво-наперво нарисуем, что бы интерфейсы на роутере отвечал через свой шлюз, это для того что бы избежать петли маршрутизации, т.е. откуда пакет пришел в наш роутер туда он и уйдет. Картину, которую мы пытаемся избежать, выглядит так: у нас есть один из шлюзов в интернет 10.1.1.1, прописан он на роутере как маршрут по умолчанию. При попытки попасть из интернета на роутер по адресу 10.2.2.2, до него пакеты дойдут, но в ответ он будет отправлять через шлюз 10.1.1.1 так как, он у нас маршрут по умолчанию. А там и канал может «лежать» и просто провайдера оборудование не будет знать про сеть 10.2.2.0/30, или задержки большие. Делаем следующие шаги: 
а. Пишем 2 листа для 2-х независимых сетей провайдера.
access-list 105 permit ip 10.1.1.0 0.0.0.3 any
access-list 106 permit ip 10.2.2.0 0.0.0.3 any 
б. рисуем карту маршрутизации
route-map r1 permit 10
match ip address 105
set ip next-hop 10.1.1.1

route-map r1 permit 15
match ip address 106
set ip next-hop 10.2.2.1

в. Применяем нашу карту, на локальную политику маршрутизатора.
ip local policy route-map r1

тут стоит отметить, что при применении карты к ip local policy будет перенаправление трафика, который генерируется на самом роутере, а трафик который не попадает под обработку роут мапа будет действовать согласно, глобальной политики маршрутизатора. Так же у нас есть и другие сети на маршрутизаторе, которые общаются только между сетями непосредственно подключенными к роутеру, для того что бы остальные сети так же имели шлюз по умолчанию достаточно добавить такого рода строку 
route-map r1 permit 30
set ip next-hop 192.168.1.2 
предполагается, что этот хоп находится на удаленном офисе, с которым нужно обмениваться трафиком с оставшимися сетями. Так как у нас 2 туннеля, через 2 провайдера, то тут справедливо сделать резервирование на случай падения основного, туннеля. Это делается с помощью SLA.
Его описали в достаточном объеме и не только на хабре, я этот момент опускаю.

немного о nat & pbr

На данный момент будем считать, что внутренняя маршрутизация у нас организована, по крайней мере, пользователи у нас ходят через proxy, в интернет к серверной сети они обращаются минуя proxy.
Но если мы оставим в таком состоянии, пользователи, прибыв на работу, захотят почитать любимые ресурсы в сети, проверить почту, а интернета у них, то нет, тогда они, убедившись что помимо личных ресурсов в сети, не работают и нужные по работе, тут сразу поднимется крик.
Что бы этого избежать, мы должны доделать дело до конца. Берем, транслируем адрес proxy в белые адреса провайдеров.

ip nat source route-map proxy1 interface GigabitEthernet0/1.40
ip nat source route-map proxy2 interface GigabitEthernet0/1.50

А тут «бабац» и не работает трансляция, nat и locacl policy, не отработают, так как для трансляции адресов, необходим маршрут в глобальной таблице маршрутизации. Т.е. необходимость прописать маршруты по умолчанию на 2-х провайдеров, никто не отменял. Ну и трекинг сюда же прикручиваем.

Маленькие мелочи и тонкости механизма.

Немножко про загрузку процессора маршрутизатора. Скажу что кушает он мало и видимой нагрузки не заметим. К примеру на каталисте 4948e при роутинге через PBR в районе 3-х гигов загрузки практически не наблюдается. Да и раз уж зашла тема по загрузке. То Скажу PBR с версии 12.0 поддерживает технологию cef (cisco express forvarding) она включена по умолчанию, для того что бы выключить cef для PBR достаточно дать команду ip route-cache policy на интерфейсе который держит карту (естественно на физическом а не на сабинтерфейсе.), который включает тем самымfast-switching который хранит маршруты в кеше и так же не сильно загружает процессор, но c fast-switching не поддерживает команду set ip default next-hop.
По этому, думаю стоит не экспериментировать, и использовать cef.
Ну и без описания и подробностей, скажу что проверять отрабатывает pbr или нет можно такими коммандами sh route-map all или имя непосредственно карты, наиболее важные данные показываются в виде: 
Policy routing matches: 76013668 packets, 3726692270 bytes

debug ip policy тут не забываем, что можно положить роутер загрузив cpu 
ключевые слова policy routed это значит что пакет ушел согласно нарисованой карты, 
и policy rejected — normal forwarding обратная ситуация, когда пакет пошел согласно глобальной таблицы.

Источник: blogsvazista.ru/policy-based-routing-pbr-config-example/