wtyd

О, т.е. dhcp_local_relay это и есть классический снупинг ?

Раньше я с другим оборудованием работал, сейчас надо на dlink реализовать работу dhcp в сети. В теории есть два способа настройки раздачи слонов адресов на свичах доступа: 1. классический dhcp snooping. Свичи снупируют dhcp-запросы среди прочего броадкаста, рассылают их только в доверенные порты, охраняют сеть от левых dhcp-серверов, а на роутере в такой схеме работает dhcp-relay, который переправляет броадкастовые запросы по юникасту на указанные dhcp-серверы. В такой схеме снупинг включается per vlan basis, т.е. только в нужных клиентских вланах, не указанные в настройках вланы не затрагиваются. 2. dhcp-relay. Это когда свич доступа снупирует dhcp-запрос и передаёт его сам без роутера юникастом на указанные dhcp серверы. Маршрутизатор тут уже не участвует, юникаст от свичей до dhcp пролетает без дополнительных настроек на роутерах сети. Я не нашёл в длинках первый вариант, там есть только второй. Может быть как-то можно включить классический снупинг в нужных вланах на длинках ? На счёт релея не всё понятно. По-моему, релей на всех вланах по-умолчанию включен. Как следует настраивать dhcp-relay на длинках ? Хочу получить схожий с первым вариантом функционал (блокировать левые серверы, не рассылать запросы во все порты кроме "серверных"/инфраструктурных, фича не должна трогать определённые транзитные вланы (!)). Как в длинках dhcp-relay работает ? Per port basis ? Видимо, надо включить фичу, потом отключить её на аплинках, на даунлинках, т.е. на портах инфраструктуры сети, в которых есть тегированные вланы. Я правильно рассуждаю ? Просто не хочется сидеть и несколько дней на лабе все эти нюансы изучать.

Специально его, говорят, никто не включал и даже не выключал :-). Проблема была, если трафик вещался стримером по гигабиту и проходил через 3560E, после переключения скорости порта стримера на 100Мбит всё стало хорошо. Как сказать линуксу, чтобы не так дерзко пакеты бустил на гигабите ? :-) # ethtool -k eth1 | grep -v fixed Features for eth1: rx-checksumming: on tx-checksumming: on tx-checksum-ip-generic: on scatter-gather: on tx-scatter-gather: on tcp-segmentation-offload: off tx-tcp-segmentation: off [requested on] tx-tcp6-segmentation: off [requested on] generic-segmentation-offload: on generic-receive-offload: on rx-vlan-offload: on tx-vlan-offload: on receive-hashing: on tx-nocache-copy: off rx-fcs: off rx-all: off может тут что-то включить/выключить ? Так выглядит на сотке. На гигабите tcp-segmentation-offload: on становится автоматически, остальные не помню :-).

На счёт "надо проверять в какие очереди попадает трафик, как они обрабатываются и так далее" -- подскажите, как это сделать на длинках и на цысках ? На цысках есть мапы, есть описанные алгоритмы, а как посмотреть очереди и используются ли они вообще ? В цысках же "mls qos" делаешь и всё, QoS включен, умолчальные настройки в полне себе нормальные, переделыватьих смысла нет. Ну и типа всё работает :-). Пакеты метятся это точно, а вот как по очередям распределяются - непонятно. В длинках вообще непонятно :-).

Это было первое, что мы сделали :-). QoS это так себе мера, значение его преувеличивают разные маркетоиды, которым надо продавать цыски. Вроде как помогает, но почему-то не так значительно, как о нём рассказывают. Лучше канал расширить, на 10г перейти, а не QoS мутить. Более эффективная мера. Мы метим пакеты потоков мультикаста dscp, шеститонник их в соответствии со своими мапами CoS'ит в p4 (по стандарту это как раз для видео), в коммутаторах это должно попадать в приоритетную очередь. CoS в тегированнх пакетах есть, смотрели снифером, но это ни на что не повлияло в нашем случае. Т.е. после включения QoS мы убедились, что пакеты метятся, в заголовке 802.1р появляется 4 вместо 0, на качество картинки это вообще никак не повлияло -- у нас нет загруженных линков, QoS только на загруженных даёт эффект. почему-то к микробурстам это либо совсем не относится, либо очень мало относится.

Да , на шетитоннике тотал дропс в сторону 3560Е не нулевой, там ещё почему-то флоу-контрол включен, хотя по-умолчанию он отлкючен и команд, включающих его, в конфиге порта нет. Странно всё это :-).

С камер вроде бы не vbr летит. Я не могу транскодить, у меня ЦПУ не справится :-). Видео кодек копируется, ffmpeg нужен только чтобы rtsp в мультик перекинуть. "Total output drops" не могу найти ни на с3560Е, ни на ДГС -- где такой счётчик надо смотреть ? Там вообще ошибок и дропов нет, я пока не нашёл их нигде. Может быть дропов и не было, были перестановки пакетов местами. В прошлый раз я тоже не нашёл дропов/ошибок, но видео сыпалось.

Ладно, так скажу, видимо, это мало кому интересно. Есть в узких кругах ограниченных лиц такой термин как микробурст. Это когда по счётчикам и по графикам интерфейс занят на половину или даже меньше, но происходят кратковременные переполнения буферов обмена коммутаторов. Поэтому со стороны выглядит всё нормально, но картинка крашится и никто не понимает почему. Это вызвано недостаточным объёмом буферов у некоторых коммутаторов. Так вот, переключение стримера с гигабита на сотку тупо затормозило процесс заполнения буфера у какого-то коммутатора в цепочке. Т.е. на гигабите вылетала пачка пакетов за N времени, а после переключения на сотку -- за 10*N. Пакеты со стримера вылетают не равномерно, а пачками. Все эти вещи трудно диагностируемы обычными инструментами. Первый раз я с этим столкнулся на юникастовом вещании камер. Сервер был включен в cisco 2960 (модель со всеми гигабитными портами, название точно не помню, у с2960 с 24х100 и 2х1Gb такой проблемы не было (!), там буферов хватало). В тот раз решили проблему переключением сервера вещания в шеститонник. В этот раз проблема возникла на мультиках, причём до шеститонника картинка шла номральная, а после шеститонника есть cisco 3560E, вот сразу после неё картинка крашилась. Нигде не было перегруженных линков, всё было чОтко, но вот так ... как мы это вылавливали -- отдельная история :-). Интеллектуальный штурм корреляции экзбиционизма и пацанства стримеров и различий в софте и в подключениях. Седых волос на моей голове наверное прибавилось. Кстати, там по дороге после 3560Е есть ещё и длинк ДГС-какой-то, в него подключали смотрелку и оценивали качество, так что точно не известно, у кого из мутаторов буферы мелкие. Но я думаю, что у цыски, т.к. есть сведения, что у всей серии 35ХХ есть такая проблема, а 2960 это урезанная версия 35ХХ, деталей к сожалению не знаю, но такая информация была :-).

Дерьмовый патч, который крошил гигабит? :) Nice try :-), но картинка по L2 не сыпалась никогда :-). Если бы крашился гигабит, то мы бы везде видели крашную картинку.

В общем, последние тесты показали значительный успех после того, как порт стримера с ffmpeg перевели с гигабита в 100 мегабит :-))). Хотелось бы услышать ваши версии ответов на вопрос, т.е. почему потоки сыпались, а после перевода интерфейса в 100 мегабит рассыпания прекратились ? Ответ я знаю, уверен в нём на 99%, просто я с такой ситуацией однажды сталкивался, скажу его позже. Хочу услышать ваши версии :-). Ну вдруг моя версия ответа неправильная ?

в таком случае было бы last change occurred 1d03h ago from port, который не портфаст. но в том то и дело, что в этом влане только 2 порта. один рутовый(не падал), а второй десигнейтед(тоже не падал...). и по show spanning-tree detail показывает что пришел TCN от рута(я делаю вывод что пришел TCN так как сам порт не падал и не поднимался). вот и вопрос в этом. как так? порт не падал а TCN как-будто генерится в линке и приходит обоим пирам. Если такое происходит не раз в минуту, т.е. не часто (раз в несколько часов), то ничего делать не надо :-). Как говорят пендосы "шыт хаппенс". Я в своё время так и не нашёл разгадку этого ребуса.

А нельзя, надо именно мультиком доставлять контент -- так же понтов больше :-). Да всё уже, решили литьём через центр :-). Здравый смысл отдыхает, а вместе с ним, как вы выразились, духовная боль :-)

Нигде нет, потому что хотите неправильного. Разруливать мультикаст на L2 та ещё задача, сейчас как раз абсолютно такую же схему перевожу на L3. Я так понимаю, юникаст и мультикаст у вас разнонаправленные, соответственно, полоса должна не общая заниматься, а ingress/egress? Да, но зачем её постоянно занимать, если бОльшую часть времени эти камеры никто не смотрит ? Уже переделали. Воткнули в DES-3028, у него мультикаст более правильно работает, чем в DES-3526 было. Гоним всё в отдельном влане в шеститонник, он уже разливает по требованию (pim'ом в другие роутеры, в mvr vlan по igmp запросу). Т.е. получается, что в ядро льём постоянно, а когда смотрим, то оно нам обратно по тем же каналам связи летит в мультике :-). Полоса позволяет, но здравый смысл - нет :-).

А где вы подписку собираетесь делать? Типа igmp join-group в ядре на интерфейсе в сторону сегмента с коммутаторами, а те начнут пропускать поток до ядра, и он там зарегистрируется? Лучше делать всё L3, пусть потоки валят на FHR, а тот регистрирует их в ядре на RP, так хотя бы будет способ сказать "постой", если потоки не нужны. Ну вот проблема как раз в том, что между источником (сервер на линуксе, который сам с себя берёт rtsp и ffmpeg'ом гонит в мультики) есть несколько свичей, в которых есть клиенты этих потоков. Обычно эти потоки вообще никто не смотрит, но вероятнее всего их будут смотреть эти самые клиенты, менее вероятно их будут смотреть клиенты за Мультикст Роутером. Поэтому хочется сделать красиво: если нет подписчиков на группу, то и не слать её вообще, если появился подписчик в промежуточном свиче, то слать эту группу туда, если появился подписчик за МР, то слать группу в МР. Я не знаю как более правильно объяснить :-). Может быть надо источник мультиков сделать тоже Мультикаст Роутером ? Типа поднять на нём pimd, как-то настроить ... я не понимаю, как это сдлеать и как тогда igmp snooping будет работать или не будет ? Разве МР будет слать igmp-join если кто-то за МР захочет смотреть группу ? По-моему, он пришлёт какое-то pim-сообщение и всё, а свичи между линуксом и МР только igmp умеют и не пропустят поток. Везде на схемах нарисовано примерно так: [MCast sourse]==[MCast Router]==[switch1]==[switch2]... а к свичам подключены клиенты. Нигде нет, чтобы клиенты могли быть где-то межу источником и МР. Наверное я хочу неправильного :-). правильно наверное будет подключить РС непосредственно в МР, собирать в него юникастом потоки по rtsp и фигачить мультики прямо в МР, так ? Просто в этом случае юникаст потоки будут постоянно выжирать полосу, а главное самые вероятные смотрельщики этих потоков будут далеко от имточника мультиков -- красиво не получается сдлеать. Как быть-то ? :-)

Есть источник мультикаста, который постоянно гонит все свои каналы в мультикаст роутер (cisco 6500), на МР есть PIM и всё работает. Можно ли как-то сделать, чтобы не постоянно гнать все потоки в МР, а по запросу ? Если гнать постоянно, что МР всегда знает, где брать поток -- sh ip mroute <group address> показывает адрес сорса правильно. Если не гнать поток, то через три минуты МР перестаёт знать маршрут и не вещает ничего. Можно ли как-то сделать, чтобы работала подписка со стороны МР на только нужные группы в источнику каналов ? Между источником и МР есть несколько свичей, которые mvr умеют. Типа если сдлеать подписку, то должна такая схема работать. Можно конечно все потоки всегда стримить в ядро сети, но хочется как-то по-умнее сделать.

ffmpeg -re попробовал, но ни на что вообще не повлияло. В мане написано, что эта опция хороша для файлов, но для live источников она как бы бесполезна, но я всёравно попробовал - различий нет.

iperf показал такие же результаты, как и тут локально показывал. Штук 7 датаграм пришло не в том порядке за 30 секунд, но видео с камеры всёравно сыпется. Гон какой-то ...

Какой-то специальный снифер ? tcpdump ничё не расскажет, покажет кучу пакетов и всё. Есть мнение, что пакеты не по порядку прилетают почему-то, но пока это тоже только гипотеза. Вы бы хоть по ссылкам походили, да изучили, стало бы понятнее что можно увидеть , а то как в 1 классе http://www.bridgetech.tv/solutions.php вот и даже мультики есть http://www.bridgetech.tv/academy_fsm.php По-моему, это всё платный софт. Затрат на платный софт у нас не предусмотрено :-), поэтому и не рассматриваю. Тут ещё мысль появилась, у нас QoS совершенно точно настроен для iptv только в ближнем сегменте, на счёт проблемного дальнего сегмента есть сомнения :-). Подскажите аналог цыскиной команды для интерфейса "mls qos trust cos/dscp" для длинков ? dscp и cos выставляются, но как реагируют на это длинки я пока не знаю. С ходу аналоги цыскиных команд найти не удалось. UPDATE: QoS не помог :-)

Какой-то специальный снифер ? tcpdump ничё не расскажет, покажет кучу пакетов и всё. Есть мнение, что пакеты не по порядку прилетают почему-то, но пока это тоже только гипотеза.

Пакет стандартный 1316 байт (188x7). Менять пробовал, приставки перестают показывать, а разные плееры показывают. Читал, что размер пакета много где захардкоден в 1316. На счёт мультикаста и юникаста: ну можно конечно, но должно же в мультике показывать :-). Тем более руководство сказало -- мультикаст и всё. Продолжаем разбираться, пока нет результатов.

Пока не было возможности -- с проблемной стороны пользователи, они ничего не хотят знать/уметь, сами пока туда не ездили. Топик и был создан с целью узнать, как диагностировать такие вещи. Что за анализатор мультикаста ? Я только ffprobe знаю и iperf. Чем ещё можно посмотреть ? Под винду под линукс

кодеры на IP камерах зачастую "спецефические" попробуйте перекодировать, и -или буферизировать видео перекодировать -- нет аппаратных мощностей это делать, а буфферизировать надо на стороне клиента или можно это в параметрах потока указать ? UPDATE: Попробовали на стороне клиента увеличить кеш до 10 секунд -- не помогло. Вы прямо таки уверены, что на камерах mpeg2? Я думаю, что там h264, отсюда и проблема половинчатого кадра после key-frame. Перекодировка спасет вас и я бы еще взял vlc, а не ffmpeg. Половинчатый кадр только в другом L3 сегменте получается, тут рядом кадр нормальный. Перекодировать 1280х720х3шт свободного тазика нет :-). Про mpeg2 я нигде вроде бы не писал, я писал про mpegts. А кодек там h264 с камер летит. Проблема, по-моему, не в кодеке. Есть несколько камер с разными разрешениями, которые в ближнем к ним L3 сегменте нормально показывают, а в другом L3 примерно по пол кадра (чем меньше разрешение тем бОльшая часть кадра нормально показывается). Так же есть туча тв-каналов, которые везде нормально показывают (хотя я уже не уверен :-)). В других L3 сегментах мы ещё не проверяли. Вот я сижу и думаю уже несколько дней, в чём проблема-то ? :-). VLC раньше был на этих же задачах, на счёт рассыпания/нерассыпания в другом L3 сегменте сети данных нет, но предыдущие админы по какой-то причине в кроне сделали рестарт ВЛЦ каждый час :-). Ещё он жрал память как слон и проц в 2 раза больше, чем ffmpeg/avconv на тех же самых потоках.

кодеры на IP камерах зачастую "спецефические" попробуйте перекодировать, и -или буферизировать видео перекодировать -- нет аппаратных мощностей это делать, а буфферизировать надо на стороне клиента или можно это в параметрах потока указать ? UPDATE: Попробовали на стороне клиента увеличить кеш до 10 секунд -- не помогло.

Ситуация такая: в сети работает iptv, вроде бы нормально. Недавно поставили задачу вещать в ту же MVR сеть потоки с камер. Сделали всё на ffmpeg -i <rtmp ссылка> -vcodec copy ... -f mpegts udp://<адрес группы> . Вещается. Так получилось, что мы сами рядом находимся и у нас всё вполне себе нормально показывается, но у абонентов, расположенных в другом L3 сегмента (мультикаст роутится туда, там свой mvr влан) есть проблемы. Проблема выражается в том ,что верхняя часть картинки показывается нормально, остальное смазано вниз. Когда картинка меняется, то в смазанной части появляются нормальные объекты движения, потом приходит очередной ключевой кадр и всё заново. Т.е. это не просто картинка сыпется, а каким-то определённым образом она сыпется :-). Ради теста зарезал с помощью tc себе полосу на сетевой карте десктопа и стал смотреть -- искажения очень похожи. Не хватает полосы и от этого видно верхнюю четверть кадра. Но при всём при этом телевидение, которое берётся у поставщиков, показывает нормально. Я сегодня вспотел сравнивать вывод ffprobe с разных источников, ничем они не отличаются, разве только полосой потока. Других различий я не нашёл. Есть потоки от ffmpeg - они сыпятся, есть потоки от поставщиков с похожими параметрами - они не сыпятся. Подскажите, куда копать ? Может у ffmpeg какой-то не такой mpegts ? Может параметры есть какие волшебные ? Задача с несколькими неизвестными. В планах промерить полосу на мультикасте с помощью iperf, но пока нет возможности -- там у всех видна (на винде iperf с мультикастом просто так не заработал :-)) и помогать мне никто не собирается. Сеть на длинках, трафик контрол смотрели - отключено везде по дороге, бандвидс контрол - тоже. Уже не знаю, что делать. iperf скорее всего покажет, что всё нормально. Ещё там линк агрегейшн на длинках собран в нескольких местах (по 2 гигабита). Каких-то других отличий от нашего сегмента больше нет. P.S. Ещё давно заметили, что поток с камеры через несколько дней на STB перестаёт показывать, но при этом vlc, mplayer и все остальные плееры на PC его показывают. Если рестартануть ffmpeg, то приставка опять начинает показывать -- забили задачу в крон :-). Подозреваю, что что-то не совсем так с самим потоком от ffmpeg всё же.

ipcad ещё есть. Кроме всего прочего в него можно через ulog слать определённые пакеты. А зачем вообще эти нетфлоу нужны ? Нынче у всех анлимиты. Да и вообще, netflow это debug, для учёта следует применять ip accounting. P.S. У нас в стране нынче тренд -- запретить работу коллекторов ;-). ИМХО надо отказываться от всего этого подсчёта пакетов, байтов, генерации и ловли нетфлоу. Надо делать так, чтобы это всё было не нужно.