Jump to content
Калькуляторы

ME-4924-10GE PBR

И снова я со своим кошачьим зоопарком :)

 

Задача: часть клиентских сетей, терминируемых на каталисте, необходимо отправлять на другой default next-hop.

Вроде как pbr элементарный:

 

Extended IP access list 103
   20 permit ip 10.211.0.0 0.0.255.255 any (1135141 matches)
!
route-map net211, permit, sequence 10
 Match clauses:
   ip address (access-lists): 103
 Set clauses:
   ip default next-hop 10.10.16.253
 Policy routing matches: 2379740 packets, 458901476 bytes

 

 

Всё вроде бы отлично: и set в наличии, и deny нет. Однако при навешивании на несколько (десятка два :) ) SVI с живым трафиком - проц уходит в 99%, грузит в основном Cat4k Mgmt LoPri и K2CpuMan Review.

Аналогичный pbr на 6500/sup720-3b работает превосходно на нескольких сотнях SVI :(

 

На всякий случай пробовал в акцесс-листе и permit any any, и вообще без акцесс-листа - всё аналогично.

 

Если навесить на 1-2 SVI, нагрузка растёт не на 99%, а на 20-40.

 

System image file is "bootflash:cat4500-entservices-mz.122-54.SG.bin"

 

Гугл выдаёт только такое:

http://webcache.googleusercontent.com/search?q=cache:bd4dQl7Mlc4J:https://tools.cisco.com/quickview/bug/CSCtu19620+&cd=1&hl=ru&ct=clnk

 

Cisco Bug: CSCtu19620 - Catalyst 4900M CPU goes to 99% when merging large PBR ACL into TCAM

Last Modified

Aug 24, 2012

Product

Cisco Catalyst 4000 Series Switches

Known Affected Releases

12.2(53)SG5 15.0(2)SG1

Description (partial)

 

Symptom:

High CPU on Catalyst 4900/4500 Sup6-E when applying policy based routing config to a layer 3 interface. The CPU will spike to 99% and remain there for several hours whiles the ACL is installed into TCAM.

 

Conditions:

The PBR policy must include a large number of class-maps.

 

Однако там иос чуть младше, да и "large number of class-maps" у меня нет. Однако есть много svi...

 

Собственно :)

- Может быть такое, что найденный в 12.2(53) баг не исправлен в 12.2(54)? (Думаю, да, но мало ли :) )

- Кто-нибуть использует pbr на 4924-10g? На каком иосе?

- Поделитесь плз иосом посвежее, если есть, особенно если у вас на нём успешно работает PBR :) Собственно, можно и "потухлее", если PBR работают и других багов не замечено.

 

Уж очень не хочется крутить vrf для такой элементарной задачи ;(

 

Заранее благодарю

Share this post


Link to post
Share on other sites

Вы уверены что вам нужен "set default ip next-hop" а не "set ip next-hop"? По документации Cisco эти настройки выполняют немного разные действия.

Share this post


Link to post
Share on other sites

Уверен. Локальные маршруты - на других кошаков, инет (default) - на брас

Share this post


Link to post
Share on other sites

Ну на 4500/4900 он вроде как более-менее полноценным заявлен ;(

Share this post


Link to post
Share on other sites

Ну 12 IOS вообще древний-древний..

У нас используется 15.0(2)SG9 - но по PBR не подскажу - этой фичей на агрегаторе не пользуемся...

Share this post


Link to post
Share on other sites

У меня 4948, нифига он не полноценный. Тоже, чуть дальше от идеологии 3560 - и проц в полку уезжает мгновенно.

Мало того, в новых ИОСах PBR имеет свойство тупо слетать, когда интерфейсы дергаются. В новых цисках так вообще полная задница с его работоспособностью.

Перехожу на Juniper из-за этих косяков.

Share this post


Link to post
Share on other sites

На 4948-10GE при похожей задаче (куча PBR на SVI) тоже столкнулся с подобной проблемой вызванной заполнением tcam и маршрутизацией через CPU.

Если надо до 500svi с pbr - дешевле использовать 3560g или 3750g.

Share this post


Link to post
Share on other sites

В новых цисках так вообще полная задница с его работоспособностью.

Перехожу на Juniper из-за этих косяков.

А, кстати, вариант. У нас десятки брасов и кошек сходятся в ex4500, надо покурить про pbr на джунах)

 

На 4948-10GE при похожей задаче (куча PBR на SVI) тоже столкнулся с подобной проблемой вызванной заполнением tcam и маршрутизацией через CPU.

Если надо до 500svi с pbr - дешевле использовать 3560g или 3750g.

А на каком иосе?

Share this post


Link to post
Share on other sites

Не помню по какой причине, но мы для PBR добавляли

conf t

int ...

ip route-cache policy

 

Может, у вас тоже что-то подобное нужно покрутить?

Share this post


Link to post
Share on other sites

в этих cisco нельзя перераспределить TCAM? в 3550/3750, чтобы заработал PBR нужно было немного памяти на QOS отсыпать. Делали sdm template routing

Share this post


Link to post
Share on other sites

В моей нельзя. Там сам принцип распределения tcam, нежели на 3650/3750 (3550 не мацал, говорить ничего не буду) иной.

 

P.S. Иногда с pbr access был вкуснее.

 

 

Share this post


Link to post
Share on other sites

Не помню по какой причине, но мы для PBR добавляли

conf t

int ...

ip route-cache policy

 

Может, у вас тоже что-то подобное нужно покрутить?

 

Пробовал, результат не изменился

Share this post


Link to post
Share on other sites

Вообщем у меня примерно так на 4948

 

 

!

interface Vlan601

ip unnumbered Loopback0 poll

ip helper-address aa.bb.cc.dd

ip policy route-map rm-pbr-old-out

no ip mroute-cache

!

access-list 103 remark pbr-old-out

access-list 103 permit ip any a.b.c.d 0.0.0.31

access-list 103 permit ip any e.f.g.h 0.0.0.63

access-list 103 permit ip any any

!

route-map rm-pbr-old-out permit 5

match ip address 103

set ip next-hop x.y.z.w

!

 

Таких SVI (c pbr) ~ 600 , около десятка различных pbr, cpu 65-70% стабильно, на ней-же крутится, ospf и pim и парочка vrf-lite, еще около 1000 SVI без pbr, суммарная полоса ~2.5-3G, из них через pbr 500-600M, софт cat4500-entservicesk9-mz.150-2.SG.bin, uptime is 1 year, 18 weeks, 2 days, 14 hours, 25 minutes.

Вообщем несколько удивлен вашими процентами.

 

 

Да, пардон - глянул у вас defaulut-next-hop вероятно это создает эту дополнительную нагрузку, у меня была несколько другая схема и необходимые локальные маршруты я пропускал мимо pbr вручную а acl.

Edited by B_Bondarenko

Share this post


Link to post
Share on other sites

Залили 150-2.SG10, через какое-то время потестируем

 

Если не взлетит - будем или vrf мучать, или джуниковские pbr изучать, или ещё как-нибуть выкручиваться :) Если взлетит - отпишусь

Share this post


Link to post
Share on other sites

Про джуны тоже интересно. Судя по всему в ближайшее время я буду переезжать с цисковских pbr на джуновские fbf

Share this post


Link to post
Share on other sites

Со сменой иоса тоже не взлетело ;(

 

sqA61UO.png

 

Подскочило под сотню на пару минут, видимо, пока заливалось в ткам, а потом стало стабильно на 20% выше, чем было

И это всего на один svi навесил ;(

Share this post


Link to post
Share on other sites

default next-hop мелкие циски не жрут, тут видимо тема такая-же, команду кушает, только обработка процессором.

Как уже писали, проще то что надо pbr-ить, засунуть в отдельный vrf с дефолтом на нужный брас, а локалку пихать в глобал или через leaking или патчкордом, или вообще в соседнюю кошку.

На шеститоннике с SUP32 проблем с этим тожет нет.

Share this post


Link to post
Share on other sites

Да про врф-лайт на таких железках я тоже начинался: ликинга между глобалом и врф нормального нет, часто не работает нормально оспф в врф, и т.д. :(

Буду думать...

Share this post


Link to post
Share on other sites

Попробуйте PBR через set ip next-hop

в Рут мапе, первой строчкой делаете ACL матчащий весь локальный трафик

типа permit ip any 10.0.0.0 0.255.255.255 и без PBRа

 

А второй строчкой уже set ip next-hop в BRAS

Share this post


Link to post
Share on other sites

Вот спасибо, как раз думал, как бы так сделать без deny в acl -)

 

Хотя, кстати, на некоторых моделях полиси без set statement тоже уходит на цпу, надо будет что-нибудь невинное навесить

Share this post


Link to post
Share on other sites

Ей может тоже подурнет, ибо, по логике вещей, данная конструкция выполняет почти аналогичное действие, что и default next-hop. Но попробовать безусловно стоит.

Share this post


Link to post
Share on other sites

Ей может тоже подурнет, ибо, по логике вещей, данная конструкция выполняет почти аналогичное действие, что и default next-hop. Но попробовать безусловно стоит.

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

 

В предложенной же конструкции сначала всё фильтруется acl'ями, которые, если повезёт, отработают на асиках, а уже потом всем подряд пакетам меняет next-hop

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this