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

Умирает Cisco 6509 из-за мультикаста высокая нагрузка CPU 6500 после сбоя

Всем привет!

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

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

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

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

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

Edited by mnemonic

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Есть!

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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. Это много или мало. От чего плясать непонятно.

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

Share this post


Link to post
Share on other sites

Теперь в часы пик нагрузка 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 поставил. не помогает

Share this post


Link to post
Share on other sites

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

 

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

 

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

Edited by zi_rus

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

надо 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 - работает.

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