IVB Posted October 25, 2012 Posted October 25, 2012 Пытаюсь настроить TV архив (запись мультикастного потока на диск с целью отложенного просмотра). Столкнулся с непонятной проблемой, решения которой не могу найти (и даже примерно не могу понять, куда копать, чтобы разобраться). На сервере установлена Убунту 12.04.1 LTS, с ядром 3.2.0-32-generic-pae. Утилитой dumprtp запускаю получение потока и перенаправляю вывод на /dev/null (ибо запись пока не важна). Поток поступает в течение 2-3 минут, затем перестает поступать. Параллельно tcpdump'ом отслеживаю мультикаст - команды LEAVE никто не посылает (но при этом поток прекращается). Сервер подключен непосредственно к Cisco Catalist 6509, являющейся ядром сети. На Циску с нескольких стримеров поступает порядка 70 мультикастных каналов, Циска является точкой рандеву (RP), сервер получает с Циски мультикаст в том же vlan'е, в котором мультикастные потоки поступают на циску, и который потом расходится по клиентским сегментам (т.е. клиенты получают мультикаст тоже из этого vlan'а). Жалоб от клиентов на то, что поток идет, а потом обрывается - не было. Вопрос - в чем может быть причина прекращения потока? Сервер, вроде бы, не при чем, т.к. с него никаких команд на отписку не поступает. Получается, "виновата" Циска - но клиенты смотрят IPTV и не жалуются. К тому же на Циске по команде show ip igmp snooping statistics interface видно, что разница между "last join" и "last leave" для того потока, на кторый я подписываюсь с сервера, составляет как раз те 2-3 минуты. Но tcpdump'ом я LEAVE от сервера не вижу... В общем, я в тупике :( Вставить ник Quote
Kompik Posted October 25, 2012 Posted October 25, 2012 Все просто :) Для того чтобы мультикаст шел без перерывов, необходимо отвечать на query от циски, а в вашем случае dumprtp этого не делает. Соответственно на циске выходит таймаут и ... все. Вам надо чтобы кто-то отвечал на query ... Вставить ник Quote
IVB Posted October 25, 2012 Author Posted October 25, 2012 Все просто :) Для того чтобы мультикаст шел без перерывов, необходимо отвечать на query от циски, а в вашем случае dumprtp этого не делает. Соответственно на циске выходит таймаут и ... все. Вам надо чтобы кто-то отвечал на query ... Да, Вы правы - всё просто. Только это не dumprtp на query не отвечает. Это я, олень, не учёл, что querier посылает запросы, чтобы проверить, кому мультикаст ещё нужен, а кому - уже нет. И на файрволе не открыл igmp запросы :( Огромное спасибо за подсказку! Не зря говорят: "Век живи - век учись. И всё равно дурнем помрёшь" Вставить ник Quote
IVB Posted October 26, 2012 Author Posted October 26, 2012 Столкнулся с очередной проблемой - и опять встал в тупик. Наверняка опять где-то сам же и накосячил - но в упор не вижу, где. Есть несколько стримеров (возьмем для простоты два). Каждый стример вещает по 6 потоков. 1-й стример вещает с адреса 192.168.150.201, второй - 192.168.150.202. 1-й стример вещает потоки с адресами 230.1.201.* (* - от 1 до 6), второй - 230.1.202.* (* - от 1 до 6). Все стримеры вещают с порта 2002 на порт 5004. Клиенты все эти потоки видят без проблем. На том же сервере, на котором я настраиваю TV-архив, потоки с первого стримера пишутся нормально, со второго - не пишутся. tcpdump'ом я вижу потоки с обоих стримеров, заходящие на сервер. на файрволе есть разрешающее правило для мультикастных потоков: # iptables -L INPUT -n -v --line-numbers Chain INPUT (policy DROP 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination (несущественные правила пропускаем) 12 0 0 ACCEPT udp -- vlan8 * 0.0.0.0/0 224.0.0.0/4 Счетчики файрвола сбрасываю перед каждым экспериментом. Запускаю dumprtp на поток с 1-го стримера - поток пишется, счетчики в 12-м правиле растут с соответствующей скоростью. Запускаю dumprtp на поток (любой из шести - эффект одинаков) со 2-го стримера - поток не пишется, счетчики остаются 0-ми, при этом tсpdump'ом я вижу этот поток в vlan8 (т.е. на сервер он заходит). OK. Если пакеты потока не попадают на правило файрвола - значит, они дропаются вышестоящим правилом. Добавляю 1-м правилом правило, разрешающее весь трафик (вообще весь, на любом интерфейсе). Счетчики на этом правиле медленно увеличиваются (я-то тоже по сети на сервере сижу), но поток со 2-го стримера даже в это правило явно не попадает. Трафик dumprtp в файл не пишется (естественно, т.к. этот трафик где-то дропается). В системе нет других таблиц, кроме filter (т.е. никаких PREROUTING в nat/mangle не существует). 1-е правило в INPUT разрешает весь трафик. Но поток со 2-го стримера где-то дропается (но я его вижу tcpdump'ом в правильном vlan'е). В логах ничего подозрительного. Где могут дропаться пакеты со второго стримера? (сервер тот же, что и в 1-м посте) Вставить ник Quote
Ivan_83 Posted October 27, 2012 Posted October 27, 2012 У меня на фре PF дропал все пакеты с опциями, это его обычное поведение, потому с игмп был полный облом. Вставить ник Quote
Kompik Posted October 29, 2012 Posted October 29, 2012 tcpdump видит пакеты до фаервола ... Честно говоря пока не совсем соображу где может быть проблема... Но с чем связано использование разных сетей? :) Почему нельзя использовать одну сеть 230.1.201.0/24? Если сделать два привила типа: -A INPUT -s 192.168.150.201 -p udp --dport 5004 -j ACCEPT -A INPUT -s 192.168.150.202 -p udp --dport 5004 -j ACCEPT Счетчики будут тикать? Возможно что опять таки нет IGMP подписки, а поток вы видите только из-за того что в одном Ethernet находитесь где мультикаст расходится по всей сети ... P.S. Думаю что проблема опять в IGMP. Подампите подписку... Вставить ник Quote
IVB Posted October 29, 2012 Author Posted October 29, 2012 tcpdump видит пакеты до фаервола ... Честно говоря пока не совсем соображу где может быть проблема... А я на Вас так надеялся ;) Но с чем связано использование разных сетей? :) Почему нельзя использовать одну сеть 230.1.201.0/24? Один стример - одна сетка. Так проще - и настраивать, и следить потом. По IP видно, с какого стримера поток. Если сделать два привила типа: -A INPUT -s 192.168.150.201 -p udp --dport 5004 -j ACCEPT -A INPUT -s 192.168.150.202 -p udp --dport 5004 -j ACCEPT Счетчики будут тикать? 201 - тикают. 202 - нет :( Возможно что опять таки нет IGMP подписки, а поток вы видите только из-за того что в одном Ethernet находитесь где мультикаст расходится по всей сети ... P.S. Думаю что проблема опять в IGMP. Подампите подписку... Этот момент я проверил одним из первых. Поток (в tcpdump) появляется с запуском утилиты dumprtp и прекращается с ее завершением. "Чужой" поток на интерфейс сервера подаваться не должен (и не подается). Вставить ник Quote
IVB Posted October 29, 2012 Author Posted October 29, 2012 Провел еще один эксперимент. На 1-м стримере на один канал повесил IP 230.1.202.7, на 2-м стримере на один из каналов повесил IP 230.1.201.7. Поток с 1-го стримера все равно принимается нормально, со 2-го - не принимается. Т.е. от адреса, на который идет вещание, поведение не зависит. Зависит только от стримера. Или от порта, которым стример подключен. Сравнил настройки 1-го и 2-го стримеров - отличий нет. Версии прошивок совпадают (железки одинаковые - PBI4000). Настройки портов, которыми стримеры подключены к Циске, тоже совпадают. Полтергейст какой-то... Вставить ник Quote
IVB Posted October 29, 2012 Author Posted October 29, 2012 Порты Циски исключены - переткнул стримеры (201-й - в порт 202-го, а 202-й - в порт 201-го), ситуация не изменилась - поток с 202-го стримера где-то дропается... Вставить ник Quote
IVB Posted October 29, 2012 Author Posted October 29, 2012 Как я и предполагал - я сам и накосячил. В мультикастном vlan'е серверу был присвоен IP адрес, совпадающий с IPадресом 2-го стримера. Пакеты с остальных стримеров принимались нормально, а со 2-го - видимо, дропались кернелом. Срочно пора в отпуск :( Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.