[Axen]

Суть проблемы - не работает PBR на Cisco Catalyst C4900M в VRF

 

Cisco IOS Software, Catalyst 4500 L3 Switch  Software (cat4500e-ENTSERVICESK9-M), Version 15.2(4)E, RELEASE SOFTWARE (fc2)
bootflash:cat4500e-entservicesk9-mz.152-4.E.bin

Access-list и object:

object-group network Hosts-route-to-ISP-Ip117 
 10.33.0.0 255.255.255.192
!
object-group network Private-Network 
 10.0.0.0 255.0.0.0
 172.16.0.0 255.240.0.0
 192.168.0.0 255.255.0.0

ip access-list extended PBR-ISP-IP-117
 deny   ip object-group Hosts-route-to-ISP-Ip117 object-group Private-Network
 permit ip object-group Hosts-route-to-ISP-Ip117 any

Route-Map:

route-map PBR-ISP-117IP permit 10
 match ip address PBR-ISP-IP-117
 set 
 set ip vrf TR-ISP-PBR next-hop 10.33.6.58

Интерфейс, на котором навешан route police

interface Vlan522
 ip vrf forwarding TR-ISP-PBR
 ip address 10.33.6.90 255.255.255.248
 no ip unreachables
 no ip proxy-arp
 standby version 2
 standby 10 ip 10.33.6.89
 standby 10 timers 2 10
 standby 10 preempt
 standby 10 authentication XXXXXXX
 standby 10 name VL522#V-TR-ISP-PBR
 standby 10 track 1 decrement 80
 no ip route-cache
 ip policy route-map PBR-ISP-117IP
 ip ospf cost 10
end

 

Есть две железки, на которых есть выход в интернет, необходимо в зависимости от источника пакета, отправлять на ту или иную железку. На одну железку, трафик уходит как маршрут по умолчанию (10.33.6.81), и не требует PBR'a, а вот на вторую (10.33.6.58), заворачивается PBR'ом.

Во время диагностики, выявил следующее, что сам то PBR работает, стоит прописать все правила в access-list'е таким образом, что бы deny стоял последним:

ip access-list extended PBR-ISP-IP-117
 permit ip host 10.33.0.0 any
 deny   ip object-group Hosts-route-to-ISP-Ip117 object-group Private-Network
 permit ip object-group Hosts-route-to-ISP-Ip117 any

 

От сюда складывается впечатление, что я либо не правильно прочитал мануалы (но ранее такие конструкции работали и на ASA 5510-x, и на Cisco 2900 series) и что то не правильно написал, либо, на C4900M access-list на пару с route-map, работает странно.

 

Прошу посмотреть взглядом со стороны, и может быть подсказать в чем может быть причина не работоспособности.

[jffulcrum]

2 часа назад, Axen сказал:

ip vrf forwarding TR-ISP-PBR

и

2 часа назад, Axen сказал:

ip policy route-map PBR-ISP-117IP

на одном и том же интерфейсе смотрятся странно. Обычно полиси вешается на входящем для перенаправляемого трафика, а VRF forwarding - на исходящем.

 

Ну и как-то непонятно, на что вообще срабатывает фильтр

 

2 часа назад, Axen сказал:

ip access-list extended PBR-ISP-IP-117

deny ip object-group Hosts-route-to-ISP-Ip117 object-group Private-Network

permit ip object-group Hosts-route-to-ISP-Ip117 any

Если читать буквально, то вы запрещаете трафик ОТ шлюза в Интернет к приватным сетям, а потом любому трафику разрешаете (и он попадет в VRF). Это именно то, что нужно?

[NikAlexAn]

Вроде как next-hop должен быть в той же подсети что и интерфейс.

И логичней поменять маршрутизацию так чтоб next-hop надо было менять только для (

ip object-group Hosts-route-to-ISP-Ip117 object-group Private-Network

)

тогда и deny не нужен.

[Axen]

Тогда может подправите меня ещё более глобально (в плане знаний)?

На 4900 поднят VRF TR-ISP-PBR , в котором три интерфейса, vlan 522 - это интерфейс, на который входит трафик от внутренних сетей. Остальные два, это интерфейсы к двум железкам с интернетом. Соответственно, policy повешен на vlan 522.

 

Команда ip vrf forwarding TR-ISP-PBR указывает, что данный интерфейс, относится к конкретному VRF, или не верно?

 

Фильтр срабатывает следующим образом:

-не обрабатывать пакеты от указанных объектов, к серым сетям

-обрабатывать все остальные пакеты от указанных объектов

 

Хочется добиться следующего, что бы определенные сети, выходили через другой IP адресс, который находится на другой железке, и для этого надо их заворачивать.

 

55 минут назад, NikAlexAn сказал:

Вроде как next-hop должен быть в той же подсети что и интерфейс.

И логичней поменять маршрутизацию так чтоб next-hop надо было менять только для (

ip object-group Hosts-route-to-ISP-Ip117 object-group Private-Network

)

тогда и deny не нужен.

Пока не могу представить, как её так можно поменять(

А по поводу того, что бы next-hop был в той же сети что и интерфейс. А как объяснить тот факт, что policy отрабатывает, если поставить сначала any, а deny опустить вниз списка фильтрации? Т.е. по факту policy правильно описан, но видимо я криво как то описал фильтр, ну или совсем не правильно все сделал в корне.

[zhenya`]

Скорее всего очередное ограничение с денаями, почитайте доку. Поди оно в hw умеет только пермиты.

[jffulcrum]

4 часа назад, Axen сказал:

Команда ip vrf forwarding TR-ISP-PBR указывает, что данный интерфейс, относится к конкретному VRF, или не верно?

Не просто к конкретному, а только к нему. Если на интерфейс придет трафик, для которого в этой таблице VRF не найдется пути - он будет отброшен. 

 

Правило VRF forwarding надо привязать к тому интерфейсу, ИЗ которого будут уходить в Интернет пакеты от избранных источников. А полиси оставляете на VLAN 552. Все, что попадет в полиси, будет отправлено в нужный VRF и поплывет дальше в мир через определенный интерфейс.

 

Соответственно, access-list сочините так, чтобы он "хватал" конкретные IP источника, которые хотите отправить в мир иным способом, а все остальное бы запрещал, чтобы не хватать лишнее. Есть замечательный хинт neq, как для source, так и для destination. Это смертный грех, некрасиво, грузит ЦП и все такое, но просто и понятно в эксплуатации, что обычно важнее.

 

 

Edited October 3, 2018 by jffulcrum

[NikAlexAn]

16 часов назад, Axen сказал:

А по поводу того, что бы next-hop был в той же сети что и интерфейс. 

Тут я не то что то ляпнул под вечер.

У меня вот на каталистах (что есть) pbr в vrf вообще не даёт создать - выдаёт ошибку типа низзя. Может конечно ios староват(12.2 какой то). Может кто знает поточней про это ограничение?

А в остальном рекомендую поискать и почитать рекомендации и ограничения по применению pbr и vrf на каталистах в вашей версии ios-а.

Про ограничения на deny читал, возможно есть ограничения на применение object-group.

[Axen]

Почитаю тогда про возможные ограничения, и попробую построить без object-group.

 

17 часов назад, jffulcrum сказал:

Правило VRF forwarding надо привязать к тому интерфейсу, ИЗ которого будут уходить в Интернет пакеты от избранных источников. А полиси оставляете на VLAN 552. Все, что попадет в полиси, будет отправлено в нужный VRF и поплывет дальше в мир через определенный интерфейс.

Почему Вы говорите правило VRF forwarding, это же просто команда, или я не прав? Если я правило понял, то интерфейс, через который будет уходить трафик (vlan517), должен быть в VRF, а vlan522, чз который трафик попадает на коммутатор, в global (т.е. без vrf)?

[zhenya`]

Что-то мне подсказывает, что 4900 старовата для пбр со сменой врф. (Vrf в grt или что-то подобное)

[Axen]

У меня честно говоря уже появились мысли, перенести на маршрутизатор серии 2900.

 

Кстати говоря, может не понятно описал, но у меня все действия происходят в одном VRF.

[Axen]

Победил. Убрал object-group в правилах фильтрации, и разбил route-map на несколько правил. Большое всем спасибо!

[pingz]

@Axen Конфиг можешь показать? 

[Axen]

В 10.10.2018 в 14:23, pingz сказал:

@Axen Конфиг можешь показать? 

Актуально ещё?

 

P.S. редко захожу просто:(

Edited December 23, 2018 by Axen

[Axen]

ip access-list extended PBR-ISP-IP-115
 permit ip any any
ip access-list extended PBR-ISP-IP-117
 permit ip 10.33.0.0 0.0.0.127 any
ip access-list extended PBR-Private-Network
 permit ip any 10.0.0.0 0.255.255.255
 permit ip any 192.168.0.0 0.0.255.255
 permit ip any 172.16.0.0 0.15.255.255
!
route-map PBR-ISP-IP permit 10
 match ip address PBR-Private-Network
!
route-map PBR-ISP-IP permit 20
 match ip address PBR-ISP-IP-117
 set ip vrf TR-ISP-PBR next-hop 10.33.6.58
!
route-map PBR-ISP-IP permit 30
 match ip address PBR-ISP-IP-115

 

Edited December 24, 2018 by Axen