PBR в vrf с использованием ip sla

[MagMike]

6509 c sup720.

есть vrf, в котором находится bgp, соединенный с внешним миром через несколько аплинков.

загрузку каналов рулю путем анонсирования определенных сетей в соответствующий канал. это влияет только на входящий трафик.

чтобы пакеты ходили симметрично, т.е. уходили тем же каналом, что и приходят, заворачивают трафик с использованием PBR. т.е. использую route-map с указанием next-hop.

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

 

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

но при правке route-map-а для PBR столкнулся с тем, что в set ip vrf vrf_name next-hop нельзя использовать track.

track доступен только если vrf не используется:

set ip next-hop verify-availability

 

попробовал в route-map не указывать vrf - роутер начинает весь трафик обрабатывать в RP. загрузка cpu подскакивает под 100% :(

 

как можно в пределах vrf настроить PBR с учетом состояния ip sla? либо может есть другая схема корректного построения PBR, чтобы учитывать доступность внешних линков?

[Дегтярев Илья]

попросить аплинков дать вам мир по bgp, самому препенды наставить на принимаемые маршруты, и забить на pbr.

 

При этом лучше анонсить все всем. Если есть большой перекос - значит неправильно выбрано сочетание аплинков.

[MagMike]

При этом лучше анонсить все всем. Если есть большой перекос - значит неправильно выбрано сочетание аплинков.

к сожалению, такой вариант не подходит.

[_user_]

6509 c sup720.

есть vrf, в котором находится bgp, соединенный с внешним миром через несколько аплинков.

загрузку каналов рулю путем анонсирования определенных сетей в соответствующий канал. это влияет только на входящий трафик.

чтобы пакеты ходили симметрично, т.е. уходили тем же каналом, что и приходят, заворачивают трафик с использованием PBR. т.е. использую route-map с указанием next-hop.

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

 

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

но при правке route-map-а для PBR столкнулся с тем, что в set ip vrf vrf_name next-hop нельзя использовать track.

track доступен только если vrf не используется:

set ip next-hop verify-availability

 

попробовал в route-map не указывать vrf - роутер начинает весь трафик обрабатывать в RP. загрузка cpu подскакивает под 100% :(

 

как можно в пределах vrf настроить PBR с учетом состояния ip sla? либо может есть другая схема корректного построения PBR, чтобы учитывать доступность внешних линков?

Есть извращенный метод через eem тупо при срабатывании определенного события через action cli менять next-hop, однако наличие event manager на 6509 c sup720 под сомнением.

 

 

[chocholl]

OER попробуйте.

 

6509 c sup720.

есть vrf, в котором находится bgp, соединенный с внешним миром через несколько аплинков.

загрузку каналов рулю путем анонсирования определенных сетей в соответствующий канал. это влияет только на входящий трафик.

чтобы пакеты ходили симметрично, т.е. уходили тем же каналом, что и приходят, заворачивают трафик с использованием PBR. т.е. использую route-map с указанием next-hop.

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

 

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

но при правке route-map-а для PBR столкнулся с тем, что в set ip vrf vrf_name next-hop нельзя использовать track.

track доступен только если vrf не используется:

set ip next-hop verify-availability

 

попробовал в route-map не указывать vrf - роутер начинает весь трафик обрабатывать в RP. загрузка cpu подскакивает под 100% :(

 

как можно в пределах vrf настроить PBR с учетом состояния ip sla? либо может есть другая схема корректного построения PBR, чтобы учитывать доступность внешних линков?

[MagMike]

Спасибо за наводку!

 

 

OER попробуйте.

это не прокатит

Note: Only border router functionality is included

 

Есть извращенный метод через eem тупо при срабатывании определенного события через action cli менять next-hop, однако наличие event manager на 6509 c sup720 под сомнением.

зато EEM имеется! пока буду разбираться...

 

но может есть еще какие способы?

 

 

 

[MagMike]

настроил EMM. работает, однако! :)

спасибо за подсказку!

 

 

 

[fozz]

ну и показали бы конфиги, что бы на сайте в гугле запомнилось =)

[MagMike]

не жалко ;)

небольшой комментарий.

есть route-map, в котором трафик от пользователей "распихивается" по внешним каналам.

например, для пользователей, работающих через ISP3, имеется такое правило:

 

route-map CUS_TO_INET permit 10
match ip address 20
set ip vrf border next-hop IPS3_GW

Возможна ситуация, когда IPS3_GW доступен, но при этом дальше него пакеты не ходят. Такое было, например, позавчера, когда у ростелекома где-то на релейном тракте проводились работы. связь со шлюзом была, bgp-сессия не падала, но пакеты наружу не уходили

 

идея в том, что выбираем какой-то удаленный хост в сети магистрала, например, где-то в москве и проверять связь до него. если связи нет - значит у магистрала проблемы где-то по пути из нашей глубинки. В этом случае достаточно либо переписать правило в роут-мапе, либо создать правило с меньшим порядковым номером, с указанием другого next-hop-а. причем, можно даже сделать default next-hop, потому что если нужный канал не работает, то без разницы каким из оставшихся каналов выкидывать трафик.

создаем ip sla:

ip sla 3
icmp-echo CHECK_HOST_ISP3 source-ip MY_SRC_IP
vrf border
frequency 10
ip sla schedule 3 life forever start-time now
!
track 3 ip sla 3 reachability
delay down 30

CHECK_HOST_ISP3 - хост, связь до которого является критерием работоспособности канала. MY_SRC_IP - ip-адрес на моем маршрутизаторе, с которого посылаются icmp echo-request. Это ip-адрес, выданный аплинком на канал между мной и им.

Ну и теперь сами обработчики падения канала или его поднятия:

event manager applet isp3_down
event track 3 state down
action 01.0 cli command "enable"
action 02.0 cli command "config terminal"
action 04.0 cli command "route-map CUS_TO_INET permit 5"
action 06.0 cli command "match ip address 20"
action 08.0 cli command "set ip default vrf border next-hop MAIN_ISP_GW"
action 10.0 cli command "end"
event manager applet isp3_up
event track 3 state up
action 01.0 cli command "enable"
action 02.0 cli command "config terminal"
action 04.0 cli command "no route-map CUS_TO_INET permit 5"
action 10.0 cli command "exit"
!

 

Повторюсь, если бы не vrf, то никаких наворотов не надо было бы - route-map-ы умеют использовать track-и, вот только не совместно с vrf.