[st_re]

Есть поставщик услуг по мультикасту. Предоставляет потоки видео (телевидение), которые нужно довести до конечных пользователей. Сейчас это все настроено на Foundary BigIron 8000, но оно, судя по всему, не желает заниматься маршрутизацией мультикаста в железе и при 100 мегабитах потока от поставщика процессор упирается в 100% и дальше идут дропы и дропы и только дропы.

В общем ищется железка, которая сможет принять 200-300 мегабит мультикаста (средний пакет там 1300 байт) с использованием mbgp и слить его в несколько вланов, откуда запросят. Интерфейсов можно 2 (да хоть 1, гигабита там получиться не должно полюбому). но вланы оно, соответственно, должно уметь.

[nashvill]

Bigiron 8000 это шасси, а модули то какие стоят?

[st_re]

В процесасе гугления по проблеме других советов, кроме как сменить бигирон на _____ я так и не увидел. но там советы довольно старые, меня интересует сейчас конкретные названия для ______. Но мысли на предмет куда стукнуть эту желеку тоже приветсвуются.

 

А так там S3: BxGMR4 M4 Management Module, SYSIF 2 M4, ACTIV 8 в качестве управления.. процессор на 466 герц.

 

telnet@BigIron Router#show cp

74 percent busy, from 141995 sec ago

1 sec avg: 96 percent busy

5 sec avg: 97 percent busy

60 sec avg: 96 percent busy

300 sec avg: 96 percent busy

 

telnet@BigIron Router#show processes cpu

Process Name 5Sec(%) 1Min(%) 5Min(%) 15Min(%) Runtime(ms)

IP_M 69.22 83.14 80.04 71.83 95219021

 

остальное стремится к 0.

 

Соответственно опускание интерфейса, откуда лезет мкаст переводит загрузку к 1...3%

mcast-hw-replic-oar

 

На порту, откуда идет мультикаст

300 second input rate: 74446200 bits/sec, 6912 packets/sec, 7.53% utilization

300 second output rate: 2344480 bits/sec, 406 packets/sec, 0.23% utilization

 

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

Изменено 19 февраля, 2009 пользователем st_re

[Stak]

Так может он только процессором и умеет? Надо по фаундри вам какой нибудь форум поискать...

[st_re]

Ну в общем я поискал, и там так и сказали на подобный вопрос, что меняйте и не мучайтесь... Я и мучаюсь ;) пытаясь выяснить на что народ посоветует.....

 

зы, что та там часть фразы выпала в предыдущем посте.. поправил.

Изменено 19 февраля, 2009 пользователем st_re

[D^2]

Maximum number of PIM or DVMRP groups – You can change the maximum number of PIM or DVMRP

groups for which the software will allocate memory. See ”Changing Dynamic Memory Allocation for IP

Multicast Groups” on page 14-2.

Defining the Maximum Number of Multicast Flows
The Multicast Flow table is shared by PIM and DVMRP. It defines the maximum number of flows for a PIM or
DVMRP multicast switching that can be written in hardware (CAM). To define the maximum number of entries for
the Multicast Flow table, enter a command such as the following:
BigIron(config)# system-max multicast-flow 2048
Syntax: system-max multicast-flow <num>
The <num> parameter specifies the maximum number of PIM and DVMRP multicast cache flows that can be
stored in the CAM. Enter a number from 512 – 2048. The default is 1024.
NOTE: Do not set this maximum too high since you may run out of resources in the CAM.

Hardware forwarding of fragmented IP multicast packets – You can enable the Layer 3 Switch to forward all

fragments of fragmented IP multicast packets in hardware. See the following sections:

 

• ”Enabling Hardware Forwarding of Multicast Traffic On Tagged Ports (JetCore only)” on page 14-6

• ”Enabling Hardware Forwarding for all Fragments of IP Multicast Packets” on page 14-9

• ”JetCore Hardware Forwarding of Multicast Traffic on Tagged and Untagged Ports” on page 14-9

Enabling Hardware Forwarding of Multicast Traffic On Tagged Ports (JetCoreonly)

(с) Foundry Enterprise Configuration and Management Guide

 

Software release 07.5.06 and later supports IPC and IGC versions that can forward multicast traffic on tagged

ports in hardware instead of sending the traffic to the CPU for forwarding. When you use these versions, multicast

traffic that needs to be forwarded on a tagged port is forwarded in hardware.

NOTE: This enhancement applies to Layer 3 multicast traffic on JetCore Layer 3 Switches only. All Layer 2

multicast traffic on JetCore or IronCore devices is forwarded by the CPU.

BigIron# show ip pim resource
allocated in-use available alloc-fail upper-limit
flow 1022 0 1022 0
PIM mcache 1024 0 1023 0
NBR list 64 0 64 0 64
interface group 256 0 256 0 2048
global group 256 0 256 0 1024
timer 256 0 256 0 1024
prune nbr 1024 0 1024 0 4096
prune 128 0 128 0 256
join/prune elem 12240 0 12240 0 48960
pimsm OIF 256 0 256 0 no-limit
IGMP group 256 0 256 0 1024
[b]HW tagged replication enabled[/b]

 

To enable hardware forwarding of multicast traffic in one-armed-router configurations, enter the following
commands:
BigIron(config)# mcast-hw-replic-oar
BigIron(config)# write memory
BigIron(config)# end
BigIron# reload

IPC and IGC Requirements
Multicast hardware forwarding for tagged ports requires at least the following IPC and IGC versions:
• IPC version 300 (ASIC version 0x48) or later
• IGC version 400 (ASIC version 0x49) or later

Изменено 20 февраля, 2009 пользователем D^2

[st_re]

mcast-hw-replic-oar есть.

multicast-flow было 1024, снизили в свое время до 512, как бы переполнять сам не должно бы...

 

telnet@BigIron Router#show ip pim resource

HW tagged replication disabled, reason: slot 1, ironcore

 

Слот 1 вообще пустой...

 

и судя по

==========================================================================
SL 3: BxGMR4 M4 Management Module, SYSIF 2 (Mini GBIC), M4, ACTIVE
      Serial #:  
8192 KB BRAM, SMC version 1, BM version 21
  512 KB PRAM(512K+0K) and 2048*8 CAM entries for DMA  8, version 0209
  512 KB PRAM(512K+0K) and shared CAM entries for DMA  9, version 0209
  512 KB PRAM(512K+0K) and 2048*8 CAM entries for DMA 10, version 0209
  512 KB PRAM(512K+0K) and shared CAM entries for DMA 11, version 0209

 

другого мне и не светит..

[cmhungry]

Есть поставщик услуг по мультикасту. Предоставляет потоки видео (телевидение), которые нужно довести до конечных пользователей. Сейчас это все настроено на Foundary BigIron 8000, но оно, судя по всему, не желает заниматься маршрутизацией мультикаста в железе и при 100 мегабитах потока от поставщика процессор упирается в 100% и дальше идут дропы и дропы и только дропы.

В общем ищется железка, которая сможет принять 200-300 мегабит мультикаста (средний пакет там 1300 байт) с использованием mbgp и слить его в несколько вланов, откуда запросят. Интерфейсов можно 2 (да хоть 1, гигабита там получиться не должно полюбому). но вланы оно, соответственно, должно уметь.

3560 кошка осилит, например

3550 наверняка тоже

[nashvill]

У меня с BXGMR4 (не JetCore) не получилось хардверно гонять мультикаст. Но помню что при каким-то определенных настройках нагрузка действительно зашкаливала под сотню и все лагало, потом как-то забил на все это мероприятие и возобновив развлечение спустя год (настраивал с нуля) получил нагрузку в районе 3-5% при достаточно большом потоке.

 

Вы случаем нигде в конфиге ip pim ttl не крутите?

[st_re]

Вы случаем нигде в конфиге ip pim ttl не крутите?

нет.... А нет возможности сравнить конфиги до того и после ? А железо осталось тем же ?

 

ip multicast-routing

ip multicast-perf
ip show-subnet-length
ip igmp query-interval 120
ip igmp group-membership-time 240

no ip source-route
ip multicast passive
ip multicast filter
ip multicast hardware-drop
    
mcast-hw-replic-oar

router pim
rp-address х.х.х.1 0
hardware-drop

router msdp
msdp-peer х.х.х.2
ttl-threshold х.х.х.2 10

interface ve 1
ip address y.y.31.2/24
ip pim-sparse
!
interface ve 3
ip address y.y.1.2/24
ip pim-sparse

..
! отсюда лезет мкаст
interface ve 11
ip address x.x.x.1/30
ip pim-sparse
ip pim border

Изменено 24 февраля, 2009 пользователем st_re

[Ilya Nikitin]

Была у меня железка HP 9304m, по сути тот же BigIron, и была проблема схожая с Вашей (отличие только в том, что не было msdp). Прошу прощения, что не дам точной причины, но копать надо в следующую сторону: насколько я помню, потоки типа (*,G) он роутит софтварно, а потоки (S,G) он роутит аппаратно. Посмотрите вывод команды sh ip pim mcache ...

У меня кажется причина была в том, что в таблице маршрутизации у железки не было маршрута до Source IP.

Хотя может я и ошибаюсь... давно было, да и возможности проверить сейчас нету...

[st_re]

Там они почемуто присутствуют попарно для каждого mc адреса. Один с IP вещающего сервера (маршрут на него есть) второй со * для rp-address

 

1    (x.x.y.194 224.0.x.16) in v11 (tag e6/8), cnt=28266
     upstream nbr is x.x.x.109 on v11 using ip route
     Sparse Mode, RPT=0 SPT=1 REG=0 MSDP Adv=0 MSDP Create=1
     L3 (SW) 1: tag e8/8(VL1018)
     fast=0 slow=1 pru=0 swL2=0 hwL2=0 tag graft 0L2C
     age=0s up-time=2m no fid, no flow,
2    (* 224.0.x.16) RP x.x.x.109, in NIL (NIL), cnt=2028
     RP is directly connected
     Sparse Mode, RPT=1 SPT=0 REG=0 MSDP Adv=0 MSDP Create=0
     L3 (SW) 1: tag e8/8(VL1018)
     fast=0 slow=1 pru=0 swL2=0 hwL2=0 tag graft 0L2C
     age=0s up-time=2m no fid, no flow,

 

И так на каждый адрес..

[Ilya Nikitin]

Там они почемуто присутствуют попарно для каждого mc адреса. Один с IP вещающего сервера (маршрут на него есть) второй со * для rp-address

 

1    (x.x.y.194 224.0.x.16) in v11 (tag e6/8), cnt=28266
     upstream nbr is x.x.x.109 on v11 using ip route
     Sparse Mode, RPT=0 SPT=1 REG=0 MSDP Adv=0 MSDP Create=1
     L3 (SW) 1: tag e8/8(VL1018)
     fast=0 slow=1 pru=0 swL2=0 hwL2=0 tag graft 0L2C
     age=0s up-time=2m no fid, no flow,
2    (* 224.0.x.16) RP x.x.x.109, in NIL (NIL), cnt=2028
     RP is directly connected
     Sparse Mode, RPT=1 SPT=0 REG=0 MSDP Adv=0 MSDP Create=0
     L3 (SW) 1: tag e8/8(VL1018)
     fast=0 slow=1 pru=0 swL2=0 hwL2=0 tag graft 0L2C
     age=0s up-time=2m no fid, no flow,

 

И так на каждый адрес..

Сорри, не могу вспомнить как фиксил :( Проблема была в строчке из первой записи.

 L3 (SW) 1: tag e8/8(VL1018)

SW значит SoftWare, а должно быть HW

По поводу того, что записей 2 - все верно, так и должно быть.

 

Кстати, а у Вас мультикаст на L2 через эту железку не ходит случаем ?

Изменено 24 февраля, 2009 пользователем Ilya Nikitin

[st_re]

Кстати, а у Вас мультикаст на L2 через эту железку не ходит случаем ?

 

Это ?

#show ip multicast
No global or local vlan snooping enabled

[cMex]

Выше Ilya Nikitin верно написал, что для построения быстрой таблицы коммутации необходимо для записей вида (S,G) иметь мультикастовые маршруты до источника (S). На Cisco это делается командой ip mroute ... При отсутствии правильной RPF-таблицы маршрутизация мультикастового трафика осуществляется процессором коммутатора.

MSDP консолидирует данный о source-active источников, а вам необходимо, например, поднять MBGP (BGP с address-family ipv4 multicast) между маршрутизаторами, чтобы получить необходимые маршруты сверху, если не хочется прописывать их руками.

Ручаться за верность данных не могу, так как с вашим выводом "sh ..." с этих железок не знаком.

Изменено 24 февраля, 2009 пользователем cMex

[st_re]

оно, как бы, есть. получено, как раз, по mbgp.

 

1    (a.b.c.194 224.0.d.16) in v11 (tag e6/8), cnt=3219943

#show ip mroute
..
4    a.b.c.192   255.255.255.240   a.b.e.109    ve11     20

 

ip роут тоже есть, без него тогда вообще не заводилось.

#show ip route a.b.c.194
        Destination        Gateway         Port       Cost   Type
        a.b.e.0/21         a.b.e.109       v11        1      S

 

 

 

[cMex]

Да, я предполагал, что это про маршрут:

upstream nbr is x.x.x.109 on v11 using ip route

Люди говорят: http://www.gossamer-threads.com/lists/nsp/foundry/15200

Добавлял командой ip route, а нет аналогичной ip mroute?

Есть аналог команды Cisco sh ip bgp ipv4 multicast?

 

http://www.gossamer-threads.com/lists/nsp/foundry — вообще, хороший архив рассылок, попытайся в нем, что-нибудь найти по теме.

Изменено 24 февраля, 2009 пользователем cMex

[st_re]

да, ip route статиком, Для мроуте есть mbgp. Можно конечно мкастные маршруты тоже статиком поприбивать, попробовать.

 

Аналогом тут :

# show ip mbgp
Total number of BGP Routes: 4
Status codes: s suppressed, d damped, h history, * valid, > best, i internal
Origin codes: i - IGP, e - EGP, ? - incomplete
    Network            Next Hop        Metric      LocPrf Weight Path
*>  a.b.e.88/29    a.b.e.109               100    0      1 i
*>  a.b.e.190/32   a.b.e.109               100    0      1 i
*>  a.b.c.176/28  a.b.e.109               100    0      1 i
*>  a.b.c.192/28  a.b.e.109               100    0      1 i

 

Спасибо за ссылку, завтра почитаю. перую ссылку я уже читал, правда в другом оформлении. Это какойто список расылки, наверное было другое хранилище.

Изменено 24 февраля, 2009 пользователем st_re

[Ilya Nikitin]

Кстати, а у Вас мультикаст на L2 через эту железку не ходит случаем ?

 

Это ?

#show ip multicast
No global or local vlan snooping enabled

Нет, я имел ввиду проходят ли через эту железку насквозь вланы, по которым ходит много мультикаста. Не терминируются на железке, а именно проходят насквозь. Просто припоминаю, что с этим тоже какие-то грабли были связаны... Кажется на таких вланах PIM нежелательно было включать.

Изменено 25 февраля, 2009 пользователем Ilya Nikitin

[st_re]

Нет, я имел ввиду проходят ли через эту железку насквозь вланы, по которым ходит много мультикаста. Не терминируются на железке, а именно проходят насквозь. Просто припоминаю, что с этим тоже какие-то грабли были связаны... Кажется на таких вланах PIM нежелательно было включать.

 

Ну да, есть вланы, заканчивающиеся более чем в 1 порту, там да, бывают свои мкаст пакеты... В некоторые такие вланы нужно отдавать телевидение, т.е. без pim там не получится, наверное

Изменено 25 февраля, 2009 пользователем st_re

[st_re]

В общем, поставили cisco WS-C3560-24TS. И теперь (не без танцев с бубном, конечно) но проблема с потерями рассосалась.

 

Другая проблема. Тот же биг айрон. к нему сбоку приклеена кошка с мултикастом. В тот порт заведены все вланы, куда надо сливать мультикаст.

 

Теперь эта штука при выключенном ip multicast шлет мультикаст во все порты, где есть искомый влан (ну это правильно, при такой настройке) что не нравится по причине флуда в ненужные порты лишним трафиком. А вот при включении ip multicast, что active, что passive, оно начинает регистрировать igmp от клиентов на нужных портах, но каждую подписанную группу шлет только в первый, подписавшийся порт (в любое количество вланов там)

 

К примеру порт 1/1 вланы 2 и 3

порт 1/2 вланы 4 и 5

 

Абонент в влане 2 подписывается 224.0.3.1

Все. Теперь абоненты из 2 и 3 влана могут смотреть канал 224.0.3.1, а абоненты из 4 и 5 (не смотря на то, что show ip multicast group покажет регистрации) не могут. Как только все абоненты из вланов 2 и 3 отпишутся от группы, сразу же трафик начинает литься в порт 1/2.

 

Причем пока была маршрутизация на самом foundary, ничего похожего небыло. но там регистрация шла не путем включения ip multicast, а ip pim-sparce на каждом порту.

 

И еще, в влане 1 включить ip multicast оно не умеет в принципе (но при наличии igmp подписки в любом другом влане трафик перестает валиться в другие порты и в 1 влане тоже..)

 

 

[shicoy]

Апну я древню тему.

В процессе полета мультикаста на этой железке выяснилось что так же идет софтовый роутинг.

show ip pim mcache

1 (* 238.1.53.12) RP 10.0.250.1, in v99 (tag e10/1), cnt=299770

upstream nbr of rp=10.0.250.1 is 91.197.175.38 on v99 using ip route

Sparse Mode, RPT=1 SPT=0 REG=0 MSDP Adv=0 MSDP Create=0

L3 (SW) 1: tag e5/4(VL3777)

fast=1 slow=0 pru=1 swL2=0 hwL2=0 tag graft 0L2C

age=0s up-time=24m fid=3bf8, no flow,

 

 

Железка работает как PIM-SM маршрутизатор

Настройки такие:

ip multicast-routing

ip dr-aggregate

no ip load-sharing

no ip source-route

no ip icmp redirects

no ip icmp unreachable

mcast-drop-sw-packet

mcast-hw-replic-oar

mcast-buf-helper

 

ip mroute 1 238.1.53.0 255.255.255.0 interface ve 99

 

interface ve 99

ip address ***.***.175.37/30

ip pim-sparse

ip ospf area 0.0.0.0

ip ospf mtu-ignore

ip igmp version 2

qos-tos

qos-tos trust dscp

 

при этом

Id IP Address Subnet Mask RPF Address Port Distan

1 238.1.53.0 255.255.255.0 0.0.0.0 ve99

 

Я так понимаю вариант *,S всегда будут маршрутизироваться софтварно, но как тогда организовать вариант маршрутизации (S,G) ?

[kdserg]

Апну я древню тему.

В процессе полета мультикаста на этой железке выяснилось что так же идет софтовый роутинг.

show ip pim mcache

1 (* 238.1.53.12) RP 10.0.250.1, in v99 (tag e10/1), cnt=299770

upstream nbr of rp=10.0.250.1 is 91.197.175.38 on v99 using ip route

Sparse Mode, RPT=1 SPT=0 REG=0 MSDP Adv=0 MSDP Create=0

L3 (SW) 1: tag e5/4(VL3777)

fast=1 slow=0 pru=1 swL2=0 hwL2=0 tag graft 0L2C

age=0s up-time=24m fid=3bf8, no flow,

 

 

Железка работает как PIM-SM маршрутизатор

 

 

Было у нас такое на Brocade TurboIron-24X. Брокадовский TAC признал это багом, обещали исправить в следующей прошивке, которой пока нет. TurboIron не переключался в SPT режим (т.е были только (*,G) записи и не было (S,G), как и у вас) и мультикаст роутился программно.

Был найден workaround, на нижестоящих PIM роутерах(это у нас L3 D-Link) было включено config pim last_hop_spt_switchover immediately

, что принудительно переключает TurboIron на аппаратный роутинг мультикаста.

Сейчас роутится 500-600 Мбит мультикаста при загрузке CPU менее 1%.

[shicoy]

Спасибо помогло :) Нагрузка действительно упала, и по show ip pim mcache видно что маршрутизация аппаратная началась, но я думал что

это источник проблемы описанной тут: http://forum.nag.ru/forum/index.php?showtopic=74567 оказалось нет. Будем копать дальше.

[telecom]

Было у нас такое на Brocade TurboIron-24X. Брокадовский TAC признал это багом, обещали исправить в следующей прошивке

Сильно повезло Вам...

С похожей проблемой multicasta бьюсь с Extreme Networks вторую неделю и безрезультатно. Три явных бага в упор видить не хотят!

 

Поправка. Завели в Extreme TAC на один из багов после десяти дней битвы.

 

Кстати, по поводу Вашего бага, Московский Брокейд о нем прямо сообщает, мол есть в определенной схеме при соседстве с Длинком с мультикастом определенные проблемы. Считаю, их такая честная и открытая позиция заслуживает уважения!

Изменено 28 апреля, 2012 пользователем telecom