MagMike Опубликовано 20 сентября, 2009 · Жалоба 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, чтобы учитывать доступность внешних линков? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 20 сентября, 2009 · Жалоба попросить аплинков дать вам мир по bgp, самому препенды наставить на принимаемые маршруты, и забить на pbr. При этом лучше анонсить все всем. Если есть большой перекос - значит неправильно выбрано сочетание аплинков. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 21 сентября, 2009 · Жалоба При этом лучше анонсить все всем. Если есть большой перекос - значит неправильно выбрано сочетание аплинков. к сожалению, такой вариант не подходит. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
_user_ Опубликовано 21 сентября, 2009 · Жалоба 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 под сомнением. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
chocholl Опубликовано 21 сентября, 2009 · Жалоба 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, чтобы учитывать доступность внешних линков? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 21 сентября, 2009 · Жалоба Спасибо за наводку! OER попробуйте.это не прокатитNote: Only border router functionality is included Есть извращенный метод через eem тупо при срабатывании определенного события через action cli менять next-hop, однако наличие event manager на 6509 c sup720 под сомнением.зато EEM имеется! пока буду разбираться... но может есть еще какие способы? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 21 сентября, 2009 · Жалоба настроил EMM. работает, однако! :) спасибо за подсказку! Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fozz Опубликовано 21 сентября, 2009 · Жалоба ну и показали бы конфиги, что бы на сайте в гугле запомнилось =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MagMike Опубликовано 21 сентября, 2009 · Жалоба не жалко ;) небольшой комментарий. есть 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. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...