[Wingman]

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

 

Задача: часть клиентских сетей, терминируемых на каталисте, необходимо отправлять на другой 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 для такой элементарной задачи ;(

 

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

[v_r]

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

[Wingman]

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

[nuclearcat]

Не получится так на многих свитчах, там PBR крайне кастрированный.

[Wingman]

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

[iostream]

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

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

[nuclearcat]

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

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

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

[passer]

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

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

[Wingman]

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

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

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

 

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

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

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

[passer]

cat4500-entservicesk9-mz.150-2.SG8.bin

[Wingman]

Чёрт, печально ;(

[g3fox]

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

conf t

int ...

ip route-cache policy

 

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

[dmvy]

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

[passer]

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

 

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

 

 

[Wingman]

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

conf t

int ...

ip route-cache policy

 

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

 

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

[B_Bondarenko]

Вообщем у меня примерно так на 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.

Изменено 19 октября, 2015 пользователем B_Bondarenko

[Wingman]

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

 

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

[nuclearcat]

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

[Wingman]

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

 

 

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

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

[dsk]

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

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

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

[Wingman]

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

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

[dazgluk]

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

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

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

 

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

[Wingman]

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

 

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

[dsk]

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

[Wingman]

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

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

 

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