Умирает Cisco 6509 из-за мультикаста

[mnemonic]

Всем привет!

Работает такая схема.

Есть две Cisco Catalyst 6509 c Sup32. Связаны между собой по 10G

На одной из цисок агрегируются вланы. ip unnumbered. Порядка 2000SVI.

Мультикаст поток приходит на ту циску которая не агрегирует. И по pim доставляет до адресата. На коммутаторах доступа MVR

 

Проблема в следующем. Когда происходить отключение мультикаст потока (по вине мультикасто держателя) а потом его включение обратно, то циска которая агрегирует вланы начинает умирать

по прерываниям. Процесс Intr доходит до 60%. При этом до этого катаклизма всё работает нормально.

 

В чем может быть проблема?

[s.lobanov]

Кто является RP?

[mnemonic]

Кто является RP?

Та циска на которую приходит поток

влан интерфейс на ней смотрит на стример с которого приходит мультикаст

Edited December 23, 2013 by mnemonic

[h1vs2]

Юникаст роут на RP циски, которая принимает поток, с циски, которая терминирует абонов, есть?

[mnemonic]

Юникаст роут на RP циски, которая принимает поток, с циски, которая терминирует абонов, есть?

Есть!

Циска на которую приходит поток отдаёт роут по OSPF

[mnemonic]

Нужен специалист по решению данной пробемы за вознаграждение.

Подробности прошу в личку.

[darkagent]

крутим по списку, можно даже на обеих железках:

mls rate-limit multicast ipv4 partial

mls rate-limit multicast ipv4 fib-miss

mls rate-limit multicast ipv4 ip-options

mls rate-limit multicast ipv4 igmp

mls rate-limit all ttl-failure

mls rate-limit multicast ipv4 pim

 

- тут есть подробное описалово что к чему: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd802ca5d6.html

еще можно подсунуть

ip multicast hardware-switching replication-mode egress

[mnemonic]

крутим по списку, можно даже на обеих железках:

mls rate-limit multicast ipv4 partial

mls rate-limit multicast ipv4 fib-miss

mls rate-limit multicast ipv4 ip-options

mls rate-limit multicast ipv4 igmp

mls rate-limit all ttl-failure

mls rate-limit multicast ipv4 pim

 

- тут есть подробное описалово что к чему: http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/prod_white_paper0900aecd802ca5d6.html

еще можно подсунуть

ip multicast hardware-switching replication-mode egress

 

Спасибо за совет. Интересно только какие цифры туда вписать.

Вот например параметр

mls rate-limit multicast ipv4 partial

по умолчанию стоит 100000 я поставил 10000. Это много или мало. От чего плясать непонятно.

Подскажите от чего отталкиваться в установке этих параметров.

[mnemonic]

Теперь в часы пик нагрузка 100%

#sh processes cpu detailed sorted | ex 0.0
CPU utilization for five seconds: 100%/65%; one minute: 100%; five minutes: 100%
PID/TID   5Sec    1Min     5Min Process             Prio  STATE        CPU
12310    92.7%   95.2%    94.8% ios-base                               2d15h
     6  61.8%   64.4%    64.5%                       21  Intr         8h50m
    25   7.5%    5.4%     2.8%                       10  Reply        3h39m
    24   7.0%    3.9%     3.4%                       10  Receive      2h38m
     3   5.2%    3.2%     2.9%                       10  Receive      2h51m
    21   3.4%    4.3%     4.1%                       10  Receive      3h26m
     1   3.2%    3.0%     3.5%                       10  Reply        3h12m
     7   1.7%    1.8%     1.7%                       22  Intr         4h43m
     8   1.2%    1.1%     1.0%                       23  Intr         6m05s
    23   0.9%    4.6%     4.1%                       10  Receive      2h40m
    18   0.8%    2.6%     3.2%                       10  Reply        2h28m

Process sbin/ios-base, type IOS, PID = 12310
CPU utilization for five seconds: 28%/65%; one minute: 27%; five minutes: 27%
Task  Runtime(ms)  Invoked  uSecs    5Sec   1Min   5Min TTY Prio Task Name
 24    49979495  17700376   2823  15.07% 16.93% 16.32%   0    M ARP Input
136    23217895   2001463  11600   4.39%  3.87%  3.77%   0    M Compute load avg
429     8433634  36755614    229   1.59%  1.22%  1.28%   0    M Port manager per
 16     8524643    506417  16833   0.87%  0.19%  0.41%   0    L Check heaps
135     1639252    664616   2466   0.83%  0.68%  0.69%   0    M IPC LC Message H
 87      112230  18882300      5   0.77%  0.76%  0.80%   0    H Net Input
  4     2586512  36840555     70   0.58%  0.45%  0.54%   0    M Service Task

 

rate-limit поставил. не помогает

[zi_rus]

надо CPP настроить и зарубить мультикаст, для начала под корень, ну может верхушку оставить на 1мбит и посмотреть

 

upd1 тут все указывает на то, что мкаст отправляется на проц, но, честно говоря, я не вижу причин почему он туда должен отправляться (по крайней мере по такому описанию, хоть бы картинка была). CPP надо настраивать и смотреть

 

upd2 вернее мне рассказывали как обстоят дела с мкастом на этих железках. если для трафика в железе явно не прошито дроп или форвардинг, то он отправляется на cpu. если интересно что тут происходит, то надо копать, если просто хочется решить проблему, то СРР думаю должен помочь, у нас также было, только на 7600, и она была РП

Edited December 24, 2013 by zi_rus

[darkagent]

Если в кратце и на пальцах - в момент "прилива", у вас "оживают" igmp группы, что создает лавинообразную нагрузку на проц (особенно если в сети вагон и две тележки тв-приставок, которые держут подписку даже в standby режиме). control-plane на 6500/7600 первично защищается через mls rate-limit. и чем меньше там будут циферки - тем меньше будет нагрузка на проц. Другое дело что перегибать палку тоже нельзя. Наберите в гоголе multicast best practice 6500 и он вам подсунет несколько полезных вайтпаперов, параметры в которых вполне возможно сгодятся и для вас.

[mnemonic]

надо CPP настроить и зарубить мультикаст, для начала под корень, ну может верхушку оставить на 1мбит и посмотреть

 

upd1 тут все указывает на то, что мкаст отправляется на проц, но, честно говоря, я не вижу причин почему он туда должен отправляться (по крайней мере по такому описанию, хоть бы картинка была). CPP надо настраивать и смотреть

 

upd2 вернее мне рассказывали как обстоят дела с мкастом на этих железках. если для трафика в железе явно не прошито дроп или форвардинг, то он отправляется на cpu. если интересно что тут происходит, то надо копать, если просто хочется решить проблему, то СРР думаю должен помочь, у нас также было, только на 7600, и она была РП

хороший совет!!!

добавил class-policy в policy-map для control-plane чисто для диапазона вещаемых мультикаст групп и ограничил до 1Мбита

Нагрузка сразу же упала по прерываниям до скромных 3%.

 

CoPP ранее настраивал по best practice. Настроил несколько политик для нужного трафика типа ssh, telnet, ospf и т.д.

А для class-default сделал police rate 32000 conform-action transmit exceed-action drop

По идее весь левый трафик к процу должен поступать в class-default и дропаться то что более 32000

Но получается 32000 pps это очень много в мультикасте и этого хватало чтобы убить проц.

 

Пробовал вообще запрещать эти мультикаст группы к процу. IPTV не пашет. Открыл 32Кbps - работает.