Перейти к содержимому
Калькуляторы

Cisco multicast process switching

Колллеги, кто знает как докапаться до причины process-свитчинга?

 

#show platform cpu packet statistics 

RkiosSysPacketMan:
Packet allocation failures: 0
Packet Buffer(Software Common) allocation failures: 374407
Packet Buffer(Software ESMP) allocation failures: 0
Packet Buffer(Software EOBC) allocation failures: 0
Packet Buffer(Software SupToSup) allocation failures: 0
IOS Packet Buffer Wrapper allocation failures: 0

Packets Dropped In Processing Overall

Total                5 sec avg 1 min avg 5 min avg 1 hour avg
-------------------- --------- --------- --------- ----------
             452476         0         0         0          0

Packets Dropped In Processing by CPU event

Event             Total                5 sec avg 1 min avg 5 min avg 1 hour avg
----------------- -------------------- --------- --------- --------- ----------
Sa Miss                         329808         0         0         0          0
L2 Router                           89         0         0         0          0
Input Acl Fwd                     2493         0         0         0          0
Sw Packet for Bridge               120086         0         0         0          0

Packets Dropped In Processing by Priority

Priority          Total                5 sec avg 1 min avg 5 min avg 1 hour avg
----------------- -------------------- --------- --------- --------- ----------
Normal                           51978         0         0         0          0
Medium                          331055         0         0         0          0
High                             69443         0         0         0          0

Packets Dropped In Processing by Reason

Reason             Total                5 sec avg 1 min avg 5 min avg 1 hour avg
------------------ -------------------- --------- --------- --------- ----------
STPDrop                            2582         0         0         0          0
NoDstPorts                       120086         0         0         0          0
Tx Mode Drop                     329808         0         0         0          0

Total packet queues 64

Packets Received by Packet Queue

Queue                  Total           5 sec avg 1 min avg 5 min avg 1 hour avg
---------------------- --------------- --------- --------- --------- ----------
Input ACL fwd(snooping)      1096950493      4076      4263      3468       3419
L2 bridge to CPU, 0           26495488       132       134       107        100
Host Learning                   329808         0         0         0          0
L2 Control                      906355         3         0         0          0
Ip Option                           48         0         0         0          0
Ttl Expired                   11452012        40        40        35         31
InputIf Fail                     38257         0         0         0          0
Mtu Fail                         20997         0         0         0          0
L2 router to CPU, 7          918606381      4080      4212      3445       3416
L3 Glean, 7                    1169533        16         5         1          1
L3 Fwd, 7                        15632         0         0         0          0
L3 Receive, 7                  6742322        53        28        19         17

Packets Dropped by Packet Queue

Queue                  Total           5 sec avg 1 min avg 5 min avg 1 hour avg
---------------------- --------------- --------- --------- --------- ----------
Input ACL fwd(snooping)      1050676573      3042      3284      2540       2391
L2 bridge to CPU, 0             141559         0         0         0          0
Host Learning                     4631         0         0         0          0
Ttl Expired                       3640         0         0         0          0
InputIf Fail                    115531         0         0         0          0
L2 router to CPU, 7             218443         0        44        21          2
L3 Glean, 7                       1284         0         0         0          0
L3 Fwd, 7                       630622         0         0         0          0
L3 Receive, 7                     7609         0         0         0          0

Мультикаст, приходящий с приемников, постоянно лезет на процессор.

В буфере пакеты помечаются как Event: Input Acl Fwd (не много Event: L2 Router)

join-ов никаких нет, маршрут к источнику вроде верный (собственно, у приемников адреса из direct-connected sudbnet).

Есть еще такой полиси:

policy-map SET-COS6
class class-default
  set cos 6
vlan configuration 320
 service-policy input SET-COS6

Но его отключение-включение ничего не меняет, то же с igmp-snooping.

Подскажите, куда копать?

 

4900M, 12.2(54)SG

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что за мультикаст льется на процессор - какие-то служебные данные типа PIM register или трафик от приемников?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Трафик от приемников. На всех интерфейсах с мультикастом ip pim sparse-mode, прописана rp (другая циска) статикой.

Раньше стояла 3560 с практически аналогичными настройками мультикаста - проц курил.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Покажите:

sh run | inc rp

sh run | inc ssm

 

Зачем дефолтный трафик метите cos 6?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

По правилам работы PIM sparse mode маршрутизатор получающий мультикаст данные от источника инкапсулирует их в сообщение PIM register и отправляет на RP (через специальный интерфейс PIM register tunnel), процесс продолжается до получения от RP сообщения PIM register stop. Поскольку на 49й туннели работают в софте предположу что по какой-то причине сообщения PIM register stop не приходят на вашу 49ю (либо приходят но не принимаются, то ли потому что не проходят проверку RPF, то ли еще по какой-то причине) и она продолжает слать на RP сообщения PIM register, в таком случае поможет поможет дэбаг PIM, просмотр статистики отправленных PIM сообщений и т.д. Как вариант можно сделать вашу 49ю RP для групп получаемых от непосредственно подключенных источников чтобы избежать отправки PIM register (если такое изменение возможно в вашей сети).

И возможен вариант некорректной схемы приема мультикаста, когда в одном вилане находятся и источники и приемники и попутно циска в этом же вилане выступает в роли приемника мультикаста для дальнейшей его маршрутизации по PIM, при такой схеме наблюдал пару раз что на CPU начинал литься мультикаст даже когда циска была RP.

 

P.S. Назначение COS пакетам работает в железе и на трафик не влияет, правда красить в COS6 моветон, он используется для протоколов маршрутизации и подобной служебной информации.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Спасибо за развернутый ответ!

Действительно дело было в pim register и локальном мультикасте. Он нужен, но только в этом влане, по этому не был включен в rp-acl (помечался как rp 0.0.0.0). Как только его добавил в acl - все поехало в железе.

 

Насчет COS - действительно очень хорошо помогает, при нагрузке на конечный порт пользователя тв не сыпет, когда приставка и комп с торрентом, например. Соглашусь, возможно, cos=6 многовато, но как то исторически так сложилось.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.