Cisco с нуля 16. Prefix-list, route-map, редистрибуция и PBR

Маршрутизатор по умолчанию принимает решения по одному критерию: адрес назначения и самый длинный подходящий префикс в таблице маршрутизации. Этого хватает, пока сеть простая. Как только появляются два провайдера, несколько протоколов маршрутизации и требования вроде «гости ходят через второй канал», нужны инструменты, которые вмешиваются в это решение. Их три: prefix-list отбирает маршруты по префиксу и длине, route-map связывает условия («что нашли») с действиями («что сделать») и PBR (policy-based routing, маршрутизация по политике) выбирает следующий узел для пакета не по адресу назначения, а, например, по адресу источника.

В этой статье вы научитесь описывать префиксы через ip prefix-list и понимать ge/le, писать route-map и не попадаться на её неявный deny. Затем применим их к BGP-соседям (продолжение статьи про BGP), разберём редистрибуцию (передачу маршрутов из одного источника в другой) и защиту от петель тегами. В конце вы направите гостевой VLAN 20 через провайдера 2, оставив остальные VLAN на провайдере 1, с автоматическим возвратом при отказе канала.

Что понадобится

Статья самостоятельная: достаточно маршрутизатора R1 в следующем состоянии. Если вы проходили серию подряд, всё уже так и есть.

• GigabitEthernet0/0/0 — провайдер 1: адрес 203.0.113.2/30, шлюз провайдера 203.0.113.1, на R1 есть маршрут по умолчанию ip route 0.0.0.0 0.0.0.0 203.0.113.1.
• GigabitEthernet0/0/2 — провайдер 2: адрес 198.51.100.2/30, шлюз провайдера 198.51.100.1. В статьях про статическую маршрутизацию и OSPF этот же порт мог быть стыком с R2 (10.0.12.1/30), а в статье про статическую маршрутизацию второй провайдер сидит на GigabitEthernet0/0/3. В этом мини-стенде второму провайдеру отдан GigabitEthernet0/0/2, и все команды ниже написаны для него.
• GigabitEthernet0/0/1 — trunk к SW1 с подинтерфейсами .10, .20, .99 и адресами .1 в VLAN 10, 20, 99 (как в статье Маршрутизация между VLAN). Это отдельный мини-стенд от HSRP: здесь R1 — единственный шлюз.
• Базовый NAT из статьи DHCP и NAT: ip nat inside на подинтерфейсах .10, .20, .99, ip nat outside на GigabitEthernet0/0/0 и правило ip nat inside source list 1 interface GigabitEthernet0/0/0 overload. Перевод NAT на два внешних интерфейса выполняется в разделе «NAT для двух провайдеров» ниже; схема с двумя каналами в целом описана в статье Два провайдера на Cisco.
• Для раздела про BGP нужны сессии с соседями 203.0.113.1 (AS 64500) и 198.51.100.1 (AS 64502) из статьи BGP: подключение к провайдеру; наша AS — 64501. Для раздела про редистрибуцию — работающий OSPF из статьи OSPF для начинающих. Если вы заменили OSPF на EIGRP по статье EIGRP, примеры с OSPF читайте как пояснение: для них приведены варианты с EIGRP. Разделы про BGP и редистрибуцию можно пропустить, если вам нужен только PBR.
• Доступ по консоли: часть шагов может нарушить связь, и консоль — самый надёжный путь назад.

Нужна привилегированная учётная запись. Не забывайте сохранять рабочую конфигурацию: copy running-config startup-config.

Prefix-list: фильтр по префиксу и его длине

ip prefix-list — это именованный список правил, каждое из которых описывает сеть и допустимую длину маски. Он нужен там, где вы работаете с маршрутами: в BGP, при редистрибуции, в route-map.

Синтаксис:

ip prefix-list ИМЯ [seq НОМЕР] {permit | deny} СЕТЬ/ДЛИНА [ge ДЛИНА] [le ДЛИНА]

Правила работы:

• Записи проверяются от меньшего seq к большему, проверка останавливается на первом совпадении.
• Если номер не указан, первая запись получает номер 5, следующие — на 5 больше. Так между записями остаётся место для вставок; лучше задавать номера явно.
• В конце списка действует неявный deny: всё, что не попало ни в одно правило, запрещено.
• Без ge и le правило совпадает только с точной сетью и точной длиной.

Чем это отличается от ACL

Список доступа (статья ACL) сравнивает адрес и wildcard-маску. Стандартный ACL при использовании для маршрутов видит только адрес сети, а расширенный выражает длину префикса неудобно и неочевидно. Через ACL трудно выразить «любая сеть внутри 10.0.0.0/8, но не длиннее /24». Prefix-list задаёт диапазон длин напрямую через ge и le, поэтому для фильтрации маршрутов (особенно в BGP) его принято использовать вместо ACL. ACL остаётся инструментом для пакетов: в PBR вы увидите, что там нужен именно он.

ge и le на примерах

Часть «СЕТЬ/ДЛИНА» задаёт фиксированные первые биты адреса, а ge (greater or equal, «не короче») и le (less or equal, «не длиннее») задают допустимый диапазон длин префикса. ge больше длины префикса в правиле, le не меньше ge (а если задан только le, то не меньше длины префикса), оба значения не больше 32.

Запись	Что совпадает
permit 198.51.100.0/24	только сама сеть 198.51.100.0/24
permit 10.0.0.0/8 le 24	любые сети из 10.0.0.0/8 с длиной от 8 до 24
permit 198.51.100.0/24 ge 25 le 26	сети внутри 198.51.100.0/24 только длиной /25 и /26
permit 0.0.0.0/0	только маршрут по умолчанию
permit 0.0.0.0/0 le 32	вообще любой маршрут
permit 0.0.0.0/0 ge 8 le 24	любые сети с длиной от 8 до 24

Запись 0.0.0.0/0 le 32 — стандартный приём «разрешить всё»: у нулевого префикса нет фиксированных битов, а le 32 расширяет диапазон до самых длинных масок.

Первый список: что мы анонсируем

Наш «публичный» блок для учебного стенда — 192.0.2.128/25. В реальной сети минимальный блок, который принимается в глобальной таблице, как правило, /24; здесь /25 взят для примера. Создадим список и проверим его.

Имена списков те же, что в статье про BGP: OUR-BLOCK (что мы отдаём провайдерам) и DEFAULT-ONLY (что принимаем).

enable
configure terminal
ip prefix-list OUR-BLOCK seq 5 permit 192.0.2.128/25
ip prefix-list OUR-BLOCK description Our public block for providers
ip prefix-list DEFAULT-ONLY seq 5 permit 0.0.0.0/0
ip prefix-list DEFAULT-ONLY description Accept only default route from provider
end
show ip prefix-list detail OUR-BLOCK

Как проверить: в выводе должен быть список OUR-BLOCK с одной записью seq 5 permit 192.0.2.128/25. Счётчик hit count растёт, когда список реально используется при фильтрации.

Пример вывода (формат зависит от версии IOS XE):

R1# show ip prefix-list detail OUR-BLOCK
ip prefix-list OUR-BLOCK:
   Description: Our public block for providers
   count: 1, range entries: 0, sequences: 5 - 5, refcount: 1
   seq 5 permit 192.0.2.128/25 (hit count: 0, refcount: 1)

Удаление записи: no ip prefix-list OUR-BLOCK seq 5. Номер можно не указывать, но тогда нужно повторить запись целиком; после удаления проверьте результат через show ip prefix-list.

Route-map: условие и действие

Route-map — это набор нумерованных записей с одним именем. Каждая запись состоит из режима (permit или deny), условий match и действий set. Синтаксис (шаблон команды, не вывод):

route-map ИМЯ [permit | deny] [НОМЕР]

Если номер не указан, используется 10. Нумеруйте с шагом 10, чтобы позже вставить запись между существующими.

Как route-map обрабатывает данные (маршрут или пакет):

1. Записи проверяются от меньшего номера к большему.
2. Если все match записи совпали и запись permit, выполняются её set, и route-map на этом завершается.
3. Если совпала запись deny, элемент отбрасывается (при редистрибуции — не передаётся, в PBR — идёт по обычной таблице маршрутизации).
4. Если условия записи не совпали, проверяется следующая запись.
5. Если не совпала ни одна запись, действует неявный deny: маршрут не пройдёт (при редистрибуции и фильтрации в BGP).

Несколько строк match в одной записи работают как «И» (должны совпасть все), а несколько объектов в одной строке match — как «ИЛИ». Запись без match совпадает со всем; запись без set ничего не меняет.

Основные match, которые вам пригодятся: match ip address ACL_или_prefix-list, match tag ЗНАЧЕНИЕ. Основные set: set local-preference, set as-path prepend, set tag, set metric, для PBR — set ip next-hop.

Типичный шаблон «запретить определённое, остальное пропустить»:

enable
configure terminal
route-map EXAMPLE-FILTER deny 10
 match tag 777
route-map EXAMPLE-FILTER permit 20
end
show route-map EXAMPLE-FILTER

Запись 10 отбрасывает маршруты с тегом 777, запись 20 без match пропускает всё оставшееся.

Как проверить: show route-map EXAMPLE-FILTER покажет обе записи, условия (Match clauses) и действия (Set clauses).

Prefix-list и route-map в BGP

Как поднять сессии и почему провайдеру нельзя отдавать всё подряд, разобрано в статье BGP: подключение к провайдеру. Здесь посмотрим на механику политики и на то, как её читать и менять. К соседу политика привязывается командами (синтаксис):

neighbor АДРЕС prefix-list ИМЯ {in | out}
neighbor АДРЕС route-map ИМЯ {in | out}

in относится к маршрутам, которые мы принимаем от соседа, out — к тем, которые анонсируем ему. Команды вводятся в режиме router bgp (или в address-family). Если политика сводится к «пропустить только эти префиксы», достаточно короткой формы с prefix-list. Если нужно ещё и менять атрибуты (set local-preference, set as-path prepend), нужна route-map, у которой внутри match ip address prefix-list. Именно так сделано в статье про BGP, поэтому мы используем те же имена: TO-ISP1, TO-ISP2 (на выход) и FROM-ISP1, FROM-ISP2 (на вход).

Что именно дают set local-preference (выбор пути для исходящего трафика) и set as-path prepend (подсказка для входящего), разобрано в статье про BGP; здесь они понадобятся только как примеры set внутри route-map.

Полные тексты route-map FROM-ISP1, FROM-ISP2, TO-ISP1, TO-ISP2 приведены в статье про BGP, здесь мы их не повторяем. Ниже показан сокращённый вариант: список OUR-BLOCK из предыдущего раздела и по одной route-map на соседа (в статье про BGP в них есть ещё set). Если вы уже вводили политику из той статьи, повторный ввод этих записей лишь входит в существующие route-map и не удаляет их set. Предполагается, что соседи 203.0.113.1 и 198.51.100.1 уже настроены в router bgp 64501: команда neighbor ... route-map для несуществующего соседа вернёт ошибку.

enable
configure terminal
ip prefix-list OUR-BLOCK seq 5 permit 192.0.2.128/25
ip prefix-list DEFAULT-ONLY seq 5 permit 0.0.0.0/0
route-map FROM-ISP1 permit 10
 match ip address prefix-list DEFAULT-ONLY
route-map FROM-ISP2 permit 10
 match ip address prefix-list DEFAULT-ONLY
route-map TO-ISP1 permit 10
 match ip address prefix-list OUR-BLOCK
route-map TO-ISP2 permit 10
 match ip address prefix-list OUR-BLOCK
router bgp 64501
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map FROM-ISP1 in
  neighbor 203.0.113.1 route-map TO-ISP1 out
  neighbor 198.51.100.1 route-map FROM-ISP2 in
  neighbor 198.51.100.1 route-map TO-ISP2 out
 exit-address-family
end
clear ip bgp 203.0.113.1 soft
clear ip bgp 198.51.100.1 soft
show ip bgp neighbors 203.0.113.1 advertised-routes
show ip bgp neighbors 198.51.100.1 advertised-routes

Если на вашей версии (например, классической IOS 15.x) neighbor ... route-map не принимается внутри address-family, введите её прямо в router bgp.

Команда clear ip bgp АДРЕС soft пересчитывает политику без разрыва сессии: изменения фильтров вступают в силу не сразу, а после мягкого сброса. Можно сбросить одно направление: soft in (принятые маршруты) или soft out (анонсируемые). Форма со звёздочкой (clear ip bgp * soft) затрагивает всех соседей сразу, поэтому на боевом устройстве указывайте адрес конкретного соседа.

Как проверить: в списке анонсируемых маршрутов у каждого соседа должна быть ровно одна сеть — 192.0.2.128/25. Анонсироваться она будет только при условии, что команда network из статьи про BGP присутствует и в таблице маршрутизации есть точно такой же маршрут (обычно статический на Null0). Иначе список будет пустым не из-за фильтра. Саму политику показывают show ip prefix-list и show route-map TO-ISP2.

Пример вывода (формат зависит от версии):

R1# show ip bgp neighbors 203.0.113.1 advertised-routes
BGP table version is 8, local router ID is 203.0.113.2
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal
Origin codes: i - IGP, e - EGP, ? - incomplete

   Network          Next Hop            Metric LocPrf Weight Path
*> 192.0.2.128/25   0.0.0.0                  0         32768 i

Если вместо этого пусто, проверьте по порядку: есть ли сеть в show ip bgp, нет ли опечатки в имени списка, проходит ли она по ge/le.

Редистрибуция между протоколами

Редистрибуция (redistribution) передаёт маршруты, известные одному источнику (статика, подключённые сети, другой протокол), в другой протокол. По умолчанию она выключена. Синтаксис:

redistribute {connected | static | ospf ID | eigrp AS | ...} [metric ЗНАЧЕНИЯ] [route-map ИМЯ] [subnets] [tag ТЕГ]

Ключевые слова зависят от получателя:

• В OSPF без слова subnets будут переданы только классовые сети без подсетей, поэтому почти всегда пишут subnets. Если метрика не указана, OSPF ставит 20 (для маршрутов BGP — 1), тип внешнего маршрута по умолчанию — E2 (внешний маршрут второго типа: его метрика не растёт по пути внутри OSPF).
• В EIGRP при передаче маршрутов из другого протокола (например, OSPF) нужна метрика из пяти значений: пропускная способность в кбит/с, задержка в десятках микросекунд, надёжность, нагрузка и MTU, например metric 10000 100 255 1 1500. Без метрики (в самой команде или через default-metric) такие маршруты не передаются. Исключение: при передаче из другого процесса EIGRP метрика переносится автоматически. В примерах ниже метрика задаётся явно, чтобы результат не зависел от значений по умолчанию.
• Метрика в самой команде redistribute приоритетнее default-metric.

Пример: статический маршрут в OSPF с фильтром

Пусть у R1 есть статический маршрут к сети филиала 192.168.60.0/24, и мы хотим сообщить о нём R2 через OSPF, но больше ничего статического не передавать. Следующий узел 10.0.100.2 — туннель из статьи про GRE; если туннеля у вас нет, замените в первой команде 10.0.100.2 на Null0 (получится ip route 192.168.60.0 255.255.255.0 Null0; что такое Null0, описано в разделе «Маршрут в «чёрную дыру»: Null0» статьи про статическую маршрутизацию). Вариант с Null0 годится только для учебной проверки: он создаёт чёрную дыру для 192.168.60.0/24, и после теста его нужно удалить (no ip route 192.168.60.0 255.255.255.0 Null0). Статика должна быть в таблице маршрутизации, иначе передавать нечего.

enable
configure terminal
ip route 192.168.60.0 255.255.255.0 10.0.100.2
ip prefix-list BRANCH-NETS seq 5 permit 192.168.60.0/24
route-map STATIC-TO-IGP permit 10
 match ip address prefix-list BRANCH-NETS
 set tag 100
router ospf 1
 redistribute static subnets route-map STATIC-TO-IGP
end
show ip ospf database external

Как проверить: на R2 команда show ip route 192.168.60.0 должна показать маршрут с признаком O E2. На R1 в show ip ospf database external появится внешний LSA (единица данных OSPF, которой маршрутизаторы обмениваются между собой) для 192.168.60.0. Любой другой статический маршрут в OSPF не попадёт: route-map без совпавшей записи отбрасывает его по неявному deny.

Если вы заменили OSPF на EIGRP (статья про EIGRP), та же route-map подключается в именованном режиме внутри topology base, а метрику нужно задать явно:

enable
configure terminal
router eigrp LAB
 address-family ipv4 unicast autonomous-system 100
  topology base
   redistribute static metric 10000 100 255 1 1500 route-map STATIC-TO-IGP
end
show ip route 192.168.60.0

На R2 маршрут появится как внешний EIGRP (D EX).

Опасность взаимной редистрибуции

Если два протокола обмениваются маршрутами в одном месте, это нормально. Опасность появляется, когда таких мест два и больше (например, два пограничных маршрутизатора между двумя протоколами): маршрут, переданный из протокола A в протокол B, может вернуться обратно в A и оказаться там предпочтительнее оригинала из-за административной дистанции или метрики (подробнее о дистанции ниже). Результат: петли или заведомо неоптимальные пути.

Условный пример: сеть X живёт в RIP (дистанция 120; RIP в серии не разбирается, он нужен только для иллюстрации). Оба пограничных маршрутизатора передают её в OSPF, где она становится внешним маршрутом с дистанцией 110, а затем получают друг от друга уже по OSPF. Так как 110 меньше 120, каждый предпочитает копию из OSPF собственному оригиналу, хотя это тот же маршрут, прошедший круг.

Конкретная пара протоколов может вести себя и безопаснее: например, внешний маршрут EIGRP имеет дистанцию 170 и при значениях по умолчанию проигрывает оригиналу. Но стоит изменить дистанции командой distance или добавить третий протокол, и картина меняется, поэтому метки ставят заранее. Механика защиты одинакова для любой пары протоколов; ниже она показана на OSPF и EIGRP.

Защита — теги. Каждый пограничный маршрутизатор помечает маршруты, которые передал, и не принимает обратно маршруты со «своей» меткой. Для примера нужны оба протокола одновременно: если вы удалили OSPF по статье про EIGRP, считайте раздел пояснением. Блок рассчитан на классический режим EIGRP (router eigrp 100). Если у вас уже есть именованный экземпляр, не вставляйте блок как есть: router eigrp 100 создаст отдельный классический процесс. Перенесите redistribute в address-family ipv4 unicast autonomous-system 100 / topology base именованного экземпляра.

enable
configure terminal
route-map OSPF-TO-EIGRP deny 10
 match tag 88
route-map OSPF-TO-EIGRP permit 20
 set tag 77
route-map EIGRP-TO-OSPF deny 10
 match tag 77
route-map EIGRP-TO-OSPF permit 20
 set tag 88
router eigrp 100
 redistribute ospf 1 route-map OSPF-TO-EIGRP metric 10000 100 255 1 1500
router ospf 1
 redistribute eigrp 100 route-map EIGRP-TO-OSPF subnets
end

Логика: маршрут, пришедший из OSPF в EIGRP, получает тег 77; когда он попытается вернуться из EIGRP в OSPF, запись 10 в EIGRP-TO-OSPF отбросит его. Обратное направление симметрично с тегом 88. Конфигурацию нужно применить на каждом пограничном маршрутизаторе.

Если у вас именованный режим EIGRP из статьи про EIGRP, те же четыре записи route-map и router ospf 1 оставьте как есть, а вместо классического router eigrp 100 используйте:

enable
configure terminal
router eigrp LAB
 address-family ipv4 unicast autonomous-system 100
  topology base
   redistribute ospf 1 metric 10000 100 255 1 1500 route-map OSPF-TO-EIGRP
end

Как проверить: show ip route МАРШРУТ у внешнего маршрута показывает строку Route tag 77 или Route tag 88. Тег сам по себе не влияет на выбор маршрута, он нужен только фильтрам.

Административная дистанция кратко

Административная дистанция (AD, administrative distance) — «степень доверия» источнику маршрута, от 0 до 255; чем меньше, тем выше доверие. Если один и тот же префикс известен двум источникам, в таблицу попадёт маршрут источника с меньшей AD.

Источник	AD по умолчанию
Подключённая сеть	0
Статический маршрут	1
eBGP (сессия между разными AS)	20
Внутренний EIGRP	90
OSPF	110
RIP	120
Внешний EIGRP	170
iBGP (внутри одной AS)	200
Неизвестный источник	255 (маршрут не используется)

Статический маршрут с повышенной AD (плавающий) мы уже разбирали в статьях про статическую маршрутизацию и про двух провайдеров. Для динамических протоколов дистанцию меняют в режиме протокола командой (синтаксис):

distance ДИСТАНЦИЯ АДРЕС WILDCARD [СТАНДАРТНЫЙ_ACL | ИМЯ_ACL]

Допустимые значения дистанции — от 10 до 255 (0–9 зарезервированы; маршруты с дистанцией 255 в таблицу не устанавливаются). Адрес с wildcard-маской (маской «наоборот», как в ACL) — это маршрутизатор-источник, от которого пришли маршруты. Необязательный стандартный ACL (в том числе именованный) дополнительно ограничивает, для каких сетей, полученных от этого источника, применяется новая дистанция. Расширенные ACL здесь не поддерживаются. Для EIGRP и RIP адрес сопоставляется с адресом соседа. В OSPF обычно сопоставляется router ID (идентификатор маршрутизатора в OSPF) маршрутизатора, анонсировавшего маршрут, а не адрес стыка; в документации Cisco это для OSPF отдельно не уточняется, поэтому проверьте router ID в show ip ospf. Например, если router ID R2 равен 10.0.12.2, то distance 115 10.0.12.2 0.0.0.0 внутри router ospf 1 понизит доверие к маршрутам OSPF, полученным от R2.

Для OSPF есть и более наглядная форма по типу маршрута: distance ospf external ЗНАЧЕНИЕ, distance ospf inter-area ЗНАЧЕНИЕ или distance ospf intra-area ЗНАЧЕНИЕ (по умолчанию везде 110). После изменений проверьте результат через show ip protocols и show ip route (поле distance у маршрута).

NAT для двух провайдеров

Этот раздел нужен всегда, когда у R1 два внешних канала и трафик может уходить через любой из них: и для PBR из этой статьи, и для резервирования по BGP или по плавающему маршруту из статей про BGP и мониторинг. Если у второго канала нет собственного правила NAT, сессия BGP может быть Established, а Интернета через резерв не будет. Выполните раздел до проверки отказа канала.

Если вы уже выполняли шаг с NAT из статьи про BGP (в show running-config | include ip nat inside source видны два правила с route-map NAT-ISP1 и NAT-ISP2), этот раздел пропустите.

Прежде чем направлять гостей ко второму провайдеру, поправьте NAT. Правило из статьи про NAT, ip nat inside source list 1 interface GigabitEthernet0/0/0 overload, транслирует любой пакет в адрес GigabitEthernet0/0/0 (203.0.113.2), даже если PBR вывел его через GigabitEthernet0/0/2. Провайдер 2 получил бы пакет с адресом источника провайдера 1 и, скорее всего, отбросил бы его. Нужны два правила, которые выбирают адрес по фактическому выходному интерфейсу: route-map с match interface и команда ip nat inside source route-map ... interface ... overload. Предполагается, что стандартный access-list 1 из статьи про NAT уже содержит внутренние сети.

enable
configure terminal
interface GigabitEthernet0/0/2
 ip nat outside
route-map NAT-ISP1 permit 10
 match ip address 1
 match interface GigabitEthernet0/0/0
route-map NAT-ISP2 permit 10
 match ip address 1
 match interface GigabitEthernet0/0/2
do clear ip nat translation *
no ip nat inside source list 1 interface GigabitEthernet0/0/0 overload
ip nat inside source route-map NAT-ISP1 interface GigabitEthernet0/0/0 overload
ip nat inside source route-map NAT-ISP2 interface GigabitEthernet0/0/2 overload
end
show running-config | include ip nat inside source
show ip nat statistics

Если на no ip nat inside source list 1 ... вернулось Dynamic mapping in use, cannot remove, значит, между очисткой и удалением успела появиться новая трансляция: повторите clear ip nat translation * и сразу удалите правило. Если не получается, на время снимите ip nat inside и ip nat outside с интерфейсов, очистите трансляции, смените правило и верните команды на место.

Как проверить: в show running-config | include ip nat inside source должны остаться только два правила с route-map NAT-ISP1 и NAT-ISP2, а старого правила list 1 быть не должно. Вспомогательно посмотрите show ip nat statistics (точный вид строк зависит от версии): GigabitEthernet0/0/0 и GigabitEthernet0/0/2 значатся как outside. Обычные пользователи VLAN 10 по-прежнему выходят в Интернет с адресом 203.0.113.2; трансляции гостей проверим после включения PBR.

Как вернуть прежний NAT

Если нужно вернуться к одному правилу из статьи про NAT (например, второй канал убран), выполните обратные команды. Трансляции опять придётся очистить, поэтому действуйте в окно обслуживания и с открытой консолью.

enable
configure terminal
do clear ip nat translation *
no ip nat inside source route-map NAT-ISP1 interface GigabitEthernet0/0/0 overload
no ip nat inside source route-map NAT-ISP2 interface GigabitEthernet0/0/2 overload
ip nat inside source list 1 interface GigabitEthernet0/0/0 overload
no route-map NAT-ISP1
no route-map NAT-ISP2
end
show running-config | include ip nat inside source

Как проверить: в выводе должна остаться единственная строка ip nat inside source list 1 interface GigabitEthernet0/0/0 overload. Если команда no ip nat inside source route-map ... вернула Dynamic mapping in use, cannot remove, повторите clear ip nat translation * и сразу удалите правило. Команду ip nat outside на GigabitEthernet0/0/2 снимите, только если порт больше не используется как внешний.

PBR: маршрутизация по политике

Обычная маршрутизация смотрит только на адрес назначения. PBR добавляет шаг перед этим: пакет, пришедший на интерфейс, проходит через route-map, и если запись совпала, то следующий узел выбирается по set. Если ничего не совпало, пакет идёт по обычной таблице маршрутизации.

Три правила PBR, которые избавят от самых частых ошибок:

• PBR работает на входящем интерфейсе. Команда ip policy route-map вешается на интерфейс, в который пакет приходит, а не на тот, из которого он должен выйти.
• В match ip address для PBR используется ACL (а не prefix-list). Пишите в нём только permit, а исключения оформляйте отдельной записью route-map с deny.
• Пакеты, созданные самим маршрутизатором, по политике интерфейса не обрабатываются. Для них есть отдельная команда ip local policy route-map (глобальный режим).

Стенд: гости — через провайдера 2

Задача: трафик VLAN 20 (192.168.20.0/24) должен уходить через провайдера 2 (GigabitEthernet0/0/2, шлюз 198.51.100.1), а VLAN 10 и 99 остаются на провайдере 1 (маршрут по умолчанию). Дополнительно: если канал провайдера 2 недоступен, гости уходят через провайдера 1, а не остаются без Интернета.

Для проверки канала используем IP SLA (измерение доступности) и объект отслеживания track (подробнее в статье про мониторинг). Номера ip sla 20 и track 20 выбраны намеренно: ip sla 1 и track 1 используются в статье про мониторинг, а track 10 — в статье про HSRP, поэтому здесь взяты свободные номера 20. Повторное использование номера молча изменит чужую проверку.

enable
configure terminal
ip sla 20
 icmp-echo 198.51.100.1 source-interface GigabitEthernet0/0/2
 frequency 5
ip sla schedule 20 life forever start-time now
track 20 ip sla 20 reachability
 delay up 30 down 15
end
show track 20

Как проверить: show track 20 должен показать, что объект в состоянии Up. Если Down, проверьте связь с 198.51.100.1 обычным ping: проверка работает только пока доступен шлюз провайдера.

Перед этим должен быть выполнен раздел «NAT для двух провайдеров» выше: без него гости, выведенные PBR через провайдера 2, получат адрес источника провайдера 1.

Теперь ACL, route-map PBR и привязка к интерфейсу.

enable
configure terminal
ip access-list extended GUEST-TO-LAN
 permit ip 192.168.20.0 0.0.0.255 192.168.0.0 0.0.255.255
ip access-list extended GUEST-NET
 permit ip 192.168.20.0 0.0.0.255 any
route-map GUEST-VIA-ISP2 deny 10
 match ip address GUEST-TO-LAN
route-map GUEST-VIA-ISP2 permit 20
 match ip address GUEST-NET
 set ip next-hop verify-availability 198.51.100.1 10 track 20
interface GigabitEthernet0/0/1.20
 ip policy route-map GUEST-VIA-ISP2
end
show ip policy
show route-map GUEST-VIA-ISP2

Как это работает:

• Запись 10 (deny) ловит трафик гостей к внутренним сетям 192.168.0.0/16 и возвращает его обычной маршрутизации, чтобы внутренний трафик не уходил к провайдеру.
• Запись 20 берёт остальной трафик гостей и направляет на 198.51.100.1 — но только пока объект track 20 в состоянии Up. Если провайдер 2 недоступен, политика перестаёт срабатывать, и трафик идёт по обычному маршруту по умолчанию через провайдера 1.
• Трафик других VLAN под политику не попадает: она висит только на подинтерфейсе .20.

Следующий узел в set ip next-hop должен быть достижим напрямую; 198.51.100.1 лежит в подключённой сети 198.51.100.0/30, поэтому подходит.

Пример вывода (условный; сокращённое имя интерфейса зависит от платформы):

R1# show ip policy
Interface           Route map
Gi0/0/1.20          GUEST-VIA-ISP2

R1# show route-map GUEST-VIA-ISP2
route-map GUEST-VIA-ISP2, deny, sequence 10
  Match clauses:
    ip address (access-lists): GUEST-TO-LAN
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
route-map GUEST-VIA-ISP2, permit, sequence 20
  Match clauses:
    ip address (access-lists): GUEST-NET
  Set clauses:
    ip next-hop verify-availability 198.51.100.1 10 track 20  [up]
  Policy routing matches: 124 packets, 9612 bytes

Как проверить результат: в show route-map GUEST-VIA-ISP2 у строки verify-availability в конце стоит состояние объекта отслеживания: [up] при рабочем канале и [down] при его падении. С гостевого устройства откройте любой внешний сайт; на R1 счётчик Policy routing matches у записи 20 должен расти, а в show ip nat translations появятся трансляции с внешним адресом 198.51.100.2. Для проверки возврата выключите канал провайдера 2 (shutdown на GigabitEthernet0/0/2 или потеря шлюза), подождите время delay down и убедитесь, что трансляции гостей теперь идут через 203.0.113.2. После теста включите интерфейс обратно командой no shutdown.

Как вернуть всё как было: снимите политику с интерфейса и, если она больше не нужна, удалите route-map и списки доступа. Гости вернутся на обычную маршрутизацию через провайдера 1. Правила NAT при этом можно оставить, либо вернуть прежнее правило по инструкции в разделе «Как вернуть прежний NAT».

enable
configure terminal
interface GigabitEthernet0/0/1.20
 no ip policy route-map
exit
no route-map GUEST-VIA-ISP2
no ip access-list extended GUEST-TO-LAN
no ip access-list extended GUEST-NET
end
show ip policy

Как проверить: show ip policy не должен больше показывать Gi0/0/1.20.

Запасной вариант set ip default next-hop: он работает наоборот — сначала смотрится обычная таблица маршрутизации, и политика срабатывает только если точного маршрута к адресу назначения нет (кроме маршрута по умолчанию). Это удобно, когда нужно «подстраховать» без перехвата того, что маршрутизатор и так знает, но для нашей задачи («гости всегда через провайдера 2») подходит set ip next-hop.

Локальная политика (ip local policy)

Пакеты, которые генерирует сам R1 (syslog, NTP, SSH-сессии с него), по политике интерфейса не проходят. Если нужно, например, отправлять syslog на 192.0.2.20 через провайдера 2, используйте локальную политику:

enable
configure terminal
ip access-list extended LOCAL-SYSLOG
 permit ip any host 192.0.2.20
route-map LOCAL-VIA-ISP2 permit 10
 match ip address LOCAL-SYSLOG
 set ip next-hop 198.51.100.1
ip local policy route-map LOCAL-VIA-ISP2
end
show ip local policy

Как проверить: show ip local policy показывает route-map, применённую к локальному трафику. Syslog по умолчанию идёт по UDP, поэтому оговорка ниже про TCP к этому примеру не относится; она важна для сессий SSH и BGP с самого маршрутизатора. У локальной политики есть оговорка из документации Cisco: TCP-трафик самого устройства нельзя направить таким способом, если в таблице маршрутизации нет записи для удалённого хоста. Держите ACL узким: если расширить его до permit ip any any, под локальную политику попадут и ваши SSH-сессии, и проверки IP SLA.

Два нюанса. Во-первых, адрес источника локального пакета обычно выбирается по обычной маршрутизации ещё до применения политики, то есть это, как правило, адрес GigabitEthernet0/0/0 (203.0.113.2); в документации Cisco по PBR это отдельно не описано, поэтому проверьте адрес источника на практике. Если он остался адресом провайдера 1, провайдер 2 может отбросить такие пакеты. Чтобы адрес источника соответствовал выбранному каналу, задайте его явно: для syslog это logging source-interface GigabitEthernet0/0/2 (подробнее в статье про мониторинг). Если для вашего сервиса подходящего source-interface нет, считайте это ограничением примера.

Во-вторых, пример выше без проверки доступности: при отказе канала провайдера 2 syslog перестанет доставляться. Для отказоустойчивости используйте, как и для гостей, set ip next-hop verify-availability 198.51.100.1 10 track 20.

Отладка PBR

Если политика не срабатывает, смотрите счётчики в show route-map. Для детальной картины есть debug ip policy: она печатает сообщения по каждому пакету; в них встречаются фразы policy match, policy routed и policy rejected -- normal forwarding (точный формат строки зависит от версии и платформы).

На ISR 4000 с IOS XE PBR выполняется в плоскости данных платформы, поэтому debug ip policy там может ничего не показать. Для разбора PBR на этих маршрутизаторах Cisco документирует менее затратный инструмент — packet-trace. Он ограничивает отслеживание нужным ACL и интерфейсом, а в выводе по пакету в разделе FIA trace (трассировка пути пакета внутри платформы ISR 4000) можно увидеть признак обработки PBR (IPV4_INPUT_PBR). Порядок такой (номера и ACL подставьте свои):

enable
debug platform condition interface GigabitEthernet0/0/1.20 ipv4 access-list GUEST-NET both
debug platform packet-trace packet 64
debug platform packet-trace packet 16 fia-trace
debug platform packet-trace enable
debug platform condition start

Числа в командах относятся к буферу пакетов, а вариант с fia-trace включает подробную трассировку пути пакета внутри платформы (в примере Cisco указаны обе команды; смысл чисел в статье не раскрыт). Тестовый трафик с гостевого устройства нужно пускать сразу после debug platform condition start. Результат смотрите командой show platform packet-trace packet 0 (номер пакета меняйте); состояние отладки показывает show debugging. В выводе ищите строку с IPV4_INPUT_PBR.

Порядок выключения в статье Cisco не описан. После теста выполните undebug all, затем show debugging и убедитесь, что отладка выключена; при необходимости отключите условия no-формами введённых команд или способом, принятым для вашей версии (например, debug platform condition stop), и сверьтесь с руководством. Если синтаксис на вашей версии отличается, ориентируйтесь на официальную статью Cisco «Configure Packet Trace to Debug PBR Traffic».

Ограничения платформ

PBR на коммутаторах Catalyst 9000 сильно урезан: из set поддерживается в основном set ip next-hop на прямо подключённый узел, set ip next-hop verify-availability на Catalyst 9300 недоступен, а set interface и set ip default next-hop не поддерживаются; по документации Catalyst 9300 PBR также нельзя совмещать на одном интерфейсе с NAT. Поэтому сценарий из этой статьи рассчитан на маршрутизатор ISR; для коммутатора смотрите руководство вашей платформы и версии. В классической IOS 15.x синтаксис основных команд такой же, а набор поддерживаемых функций зависит от модели.

Типичные ошибки

• Route-map без permit в конце. Вы написали несколько записей deny или permit с условиями и ждёте, что остальное пройдёт. Из-за неявного deny всё остальное пропадает. Добавьте последнюю запись permit без match.
• ACL в PBR шире нужного. permit ip any any в match ip address перехватывает весь трафик на интерфейсе, включая внутренний. Ограничивайте источник (и при необходимости назначение) и выводите исключения отдельной записью deny в route-map.
• ip policy route-map на выходном интерфейсе. PBR смотрит на пакеты, входящие в интерфейс. Политика на GigabitEthernet0/0/2 ничего не сделает с гостями, которые приходят на GigabitEthernet0/0/1.20.
• PBR сработал, а трафика нет. Две частые причины. Следующий узел недоступен: set ip next-hop требует адреса в непосредственно подключённой сети (для удалённого next-hop существует отдельная команда set ip next-hop recursive), иначе пакеты пойдут по обычной таблице; проверяйте ping до next-hop и состояние track. Или NAT: старое правило с list 1 транслирует гостей в адрес провайдера 1 даже при выходе через GigabitEthernet0/0/2; нужны правила через route-map с match interface (раздел «NAT для двух провайдеров»).
• Фильтр BGP применили, а мягкий сброс не сделали. Политика по-прежнему старая, и вы ищете ошибку там, где её нет. После правки prefix-list или route-map выполните clear ip bgp АДРЕС soft.
• Взаимная редистрибуция в двух местах без тегов. Если два пограничных маршрутизатора передают маршруты друг другу между протоколами, без set tag и отбрасывания своих меток на возврате вы рискуете получить петли или странные пути.

Что дальше

• Cisco с нуля 15. BGP: подключение к провайдеру — основы, на которых строятся фильтры из этой статьи.
• Cisco с нуля 17. GRE-туннели — связь с филиалом, через которую можно передавать и маршруты.
• Cisco с нуля 21. Мониторинг: SNMPv3, syslog, NTP, IP SLA — подробнее о проверках доступности, которыми мы воспользовались для track.
• Два провайдера на Cisco — резервирование выхода в Интернет на более простом уровне.