[a-zazell]

Здравствуйте, есть Cisco WS-C3550-12G Version 12.2(50)SE. Настроен multicast routing, в стандартном режиме работы (на аплинке принимаем кучу каналов и отдаем в SVI где дальше MVR):

 

c3550#show processes cpu sorted | e 0.00
CPU utilization for five seconds: 3%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
  8   130945836 449565257        291  0.71%  0.41%  0.45%   0 ARP Input
 93   4178273321286734373        324  0.55%  0.24%  0.37%   0 IP Input
 56   773870372 466795563       1657  0.39%  0.71%  0.72%   0 L3MD_STAT
 51   289092240 144743152       1997  0.31%  0.38%  0.39%   0 Vegas Statistics
176    65693476 471668606        139  0.23%  0.12%  0.12%   0 EIGRP-IPv4:
177    84712316 444771202        190  0.15%  0.23%  0.23%   0 EIGRP-IPv4: Hell

 

При включении pim passive на SVI клиента (вещает поток к нам), первые 10-20 сек просмотра на VLC нормально, потом резкий скачок до 70-80% процесса Ip Input:

 

#show processes cpu sorted | e 0.00
CPU utilization for five seconds: 99%/19%; one minute: 30%; five minutes: 32%
PID Runtime(ms)   Invoked      uSecs   5Sec   1Min   5Min TTY Process
 93   4178103161286712656        324 71.57% 18.83% 19.22%   0 IP Input
178       10008      1451       6897  2.62%  1.77%  1.45%   3 Virtual Exec
150    26372824 319980042         82  1.35%  0.43%  0.38%   0 PIM Process
 43     13965641816387220          0  1.19%  0.24%  0.21%   0 Vegas LED Proces
 56   773857672 466785774       1657  0.79%  0.80%  0.79%   0 L3MD_STAT
  8   130938540 449550322        291  0.47%  0.46%  0.50%   0 ARP Input
 60      527524  72669914          7  0.23%  0.03%  0.03%   0 PI MATM Aging Pr
 58      5086361024480989          0  0.23%  0.07%  0.07%   0 VegasPM
 51   289086280 144740090       1997  0.23%  0.35%  0.37%   0 Vegas Statistics
 54    10720756  41177652        260  0.15%  0.04%  0.01%   0 VL2MM
 52     18408441009089574          1  0.15%  0.11%  0.11%   0 HMATM Learn proc
177    84708384 444758526        190  0.15%  0.22%  0.21%   0 EIGRP-IPv4: Hell
127     1775320   3651629        486  0.07%  0.07%  0.06%   0 TPLUS

 

И растут счетчики Receive cef not-cef-switched:

 

c3550#show cef not-cef-switched
% Command accepted but obsolete, see 'show (ip|ipv6) cef switching statistics [feature]'

IPv4 CEF Packets passed on to next switching layer
Slot  No_adj No_encap Unsupp'ted Redirect  Receive  Options   Access     Frag
RP         0       0   136193444        0 918083396     5527   520087        0
c3550#show cef not-cef-switched
% Command accepted but obsolete, see 'show (ip|ipv6) cef switching statistics [feature]'

IPv4 CEF Packets passed on to next switching layer
Slot  No_adj No_encap Unsupp'ted Redirect  Receive  Options   Access     Frag
RP         0       0   136193445        0 918084481     5527   520087        0

 

На SVI одна клиентская подсеть без ACL. От клиента 1k pps (кстати Receive растет на 1k в секунду примерно) и поток до 15Мбит/с.

 

Ограничение платформы?

 

UPD: Добавил схемку

Изменено 26 мая, 2013 пользователем a-zazell

[h1vs2]

Юникаст роут в сторону стримера у Вас есть? Проблема обычно в этом

[a-zazell]

Юникаст роут в сторону стримера у Вас есть? Проблема обычно в этом

 

Да, connected на 3550, что-то вроде:

 

int vl100
descr Transport
ip addr 172.16.0.100 255.255.255.0
ip pim sparce-mode
!
int vl200
descr Client
ip addr 192.168.100.1 255.255.255.252
ip pim passive

 

Адрес стримера 192.168.100.2.

[nnm]

А multicast-поток до клиента доходит? Клиент в другом сегменте или в том-же, что и стример?

[a-zazell]

А multicast-поток до клиента доходит? Клиент в другом сегменте или в том-же, что и стример?

 

Клиент (я) по L3 доступен (разные подсети на разных железках), поток идет без проблем.

Изменено 12 апреля, 2013 пользователем a-zazell

[zhenya`]

а rp прописана? ip pim rp-address

[a-zazell]

а rp прописана? ip pim rp-address

 

Да конечно, IPTV у клиентов 3550 показывает без проблем. Как только сурс поднимается в клиентском интерфейсе, CPU растет.

[a-zazell]

Здравствуйте, провели апгрейд, хочу поделиться наблюдениями и может получить помощи в решении ситуации.

Заменили Cisco c3550 на с4924-10g, ситуация не поменялась - CPU росло с 10% до 40%. В mroute было:

 

c4924#sh ip mroute 238.1.1.92
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group
      V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 238.1.1.92), 22:39:35/stopped, RP 1.1.1.1, flags: SPF
 Incoming interface: Vlan555, RPF nbr 172.16.16.16
 Outgoing interface list: Null

(2.2.2.2, 238.1.1.92), 22:39:35/00:03:29, flags: FT
 Incoming interface: Vlan294, RPF nbr 0.0.0.0, Registering
 Outgoing interface list:
   Vlan555, Forward/Sparse, 22:38:56/00:03:00, H, A

 

Cisco.com говорит, что если для группы в состоянии (S,G) висит флаг F - Registering, то вроде как процесс регистрации источника не завершается, и эти пакеты идут на ЦПУ (были еще состояния Registering(data-header)). +F - говорит, что источник connected. Фильтры убирал, да и если бы проблема была в них, то потока не было бы и mroute тоже.

 

Когда перенес интерфейс источника на RP, CPU упало (см. вложение), на RP видим:

 

#sh ip mroute 238.1.1.92
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
      L - Local, P - Pruned, R - RP-bit set, F - Register flag,
      T - SPT-bit set, J - Join SPT, M - MSDP created entry,
      X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
      U - URD, I - Received Source Specific Host Report,
      Z - Multicast Tunnel, z - MDT-data group sender,
      Y - Joined MDT-data group, y - Sending to MDT-data group
      V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 238.1.1.92), 5d22h/stopped, RP 1.1.1.1, flags: SJC
 Incoming interface: Null, RPF nbr 0.0.0.0
 Outgoing interface list:
   Vlan100, Forward/Sparse-Dense, 00:00:19/00:02:40, H

(2.2.2.2, 238.1.1.92), 5d22h/00:02:57, flags: TA
 Incoming interface: Vlan995, RPF nbr 0.0.0.0
 Outgoing interface list:
   Vlan100, Forward/Sparse-Dense, 00:00:19/00:02:40, H

 

Может у кого есть схема похожая на Cisco, не сталкивались с проблемой?

[darkmatter]

Как вам уже стало понятно проблема заключается в том, что пакеты мултикаст стрима не свитчатся в асиках, а происходит процесс-свитчинг. Для того, чтобы выявить проблему, рекомендую включить debip ip packets и всм станет понятно что именно происходит не так. Т.е. циска кинет вам в лог почему она не может правильно маршрутизировать этот поток. Вероятнее всего проблема в построении rpf. Было бы нелохо, если бы вы выложили сюда конфиг pim и rp. Плюс можете посмотреть на эту статью http://www.cisco.com/en/US/products/hw/switches/ps646/products_tech_note09186a008078ece1.shtml

 

Удачи в траблшутинге.