drag0mir

Добрый день друзья. Надеюсь на вашу помощь. Имею вот такую схему мультикаст сети: Как видно из схемы, мультикаст беру у поставщика (PIM) и затем каталист с микротиком связал протоколом PIM. А дальше уже на микротике интерфейсы добавляю в PIM и в них гоню мультикаст. Вроде всё просто и понятно. и схема работает, но работает с одним багом. А баг такой: если на обоих интерфейсах ovpn1.vlan400 и ovpn2.vlan400 кто-то вступил в группу 239.195.0.1 одновременно, то поток мультикаст идет только на один из интерфейсов, а на второй уже не идет. В результате получается, что на одном объекте(интерйфейсе), если кто-то смотрит "первый канал"(не сочтите за рекламу))), то на втором объекте (интерфейсе) этот "первый канал" не кажет. Остальные все каналы показывают на втором интерфейсе (при условии что их не смотрят на первом). При этом хочется отметить, что такой приоритет 1-го интерфейса перманентный и он доминирует над вторым всегда, не важно с какого интерфейса клиент первым вступил в группу, получать поток будет только первый интерфейс ovpn1.vlan400 Единственное, как можно сменить приоритет, это по-моему в другом порядке добавить интерфейсы в PIM протокол, но суть не в этом конечно. Нужно, чтоб на все интерфейсы посылались все потоки. Ниже привожу настройки и доказательства, а также еще интересные моменты. Настройки этих самых интерфейсов: IGMP-groups. Здесь видно, что на обоих интерфейсах клиенты вступили в группу 239.195.0.11: А здесь видно что поток 239.195.0.11 якобы уходит на оба интерфейса: Но если мы снифим этот самый второй интерфейс, то видим, что в реале туда уходит только один поток 239.195.0.1 Подскажите в чем может быть проблема? Что не так с этой PIM-маршрутизацией? Скажу сразу, что если интерфейс со стороны клиента один, то всё работает прекрасно, но маршрутизация же нужна как раз для того, чтоб иметь много интерфейсов, а не один )) Заранее очень благодарен

не исправили, но по советам с этого же форума я попробовал управление сделать через порт config и выключить inband, после этого проц стал жевать мультикаст и не умирать

у нас расстояние 5 км и между антеннами стояла опора ЛЭП по середине, казалось бы не должна мешать вроде она же конструкция из металла, а не стена. но сигнал был фиговый. Поэтому мы перенесли одну антенну на другой угол дома, чтоб чуть-чуть сместить трассу, чтоб по прямой проходил сигнал чуток сбоку от опоры и сигнал сразу стал значительно лучше. мост я думаю это серьезнее чем опора ЛЭП и расстояние 11 км тоже значительно серьезнее. у нас есть линк на таком растоянии из аирфиберов. в дождик всегда падает линк

Сделайте управление outband, только через config порт, и всё будет работать. Есть такой баг, что при inband управлении весь мультикаст попадает на CPU управления. Перенос управления на выделенный config порт решает эту проблему. В inband он и при 20-30 может отваливаться. Годится, если управление в на по отдельному порту сделать. Подскажите пожайлуйста, вот у меня есть линк на airfiber при чем версия 1.5 решена ли там эта проблема с мультиком? Потому что я не совсем понимаю, если сделать на обоих концах outband (управление через порты config) то будет ли доступ на удаленную антенну? либо делать её тогда в отдельной подсети?

всем спасибо )) проблему решил )) отвечаю сам себе ну и вдруг кому-нибудь пригодится. Во-первых, обновил прошивку на dlink-dgs3120 с версии 2.00 до 3.00.022, судя по их отчетам в этой версии устранено около 70 багов, в том числе около 7 связано с igmp и мультикастом. Во-вторых, чтоб сам dlink обрубал потоки выключил опцию "Data Driven Learning Aged Out : Disabled" (устаревание изучения), когда она включена - fast leave игнорируется. В-третьих, этот dlink подменял в пакетах leave адрес отправителя на 0.0.0.0 из-за этого MikroTik игнорировал эти пакеты. Поэтому включил на dlinke опцию "Proxy Reporting : Enabled" (отправка пакетов report и leave из под указанного ip в сторону мультикаст-роутера) и опцию "Proxy Reporting Source IP : 10.40.20.250" (ip-адрес, с которого будут отправляться report-ы и leave-ы), что также важно - этот ip-адрес, должен находиться в одной подсети с ip-адресом multicast-роутера, иначе эти пакеты тоже будут игнорироваться. После этих манипуляций, всё заработало, mikrotik начал обрубать потоки по leave-ам

вот вырезка из конфига # IGMP_MULTICAST_VLAN config igmp_snooping multicast_vlan forward_unmatched disable # MLD_MULTICAST_VLAN config mld_snooping multicast_vlan forward_unmatched disable # MCFILTER config multicast vlan_filtering_mode vlanid 400 forward_all_groups # IGMP_SNOOPING config igmp_snooping vlan_name iptv fast_leave enable proxy_reporting state disable source_ip 192.168.220.50 state enable config igmp_snooping querier vlan_name iptv query_interval 75 max_response_time 10 robustness_variable 2 last_member_query_interval 1 state disable version 3 config igmp_snooping data_driven_learning vlan_name iptv state enable aged_out enable expiry_time 100 извините пожалуйста, но не понял схемы )) разъясните для дураков пожалуйста )

блин, решение конечно хорошее, но нам не подходит, так как между микротиками openvpn-туннель, через который прокинут 400-ый vlan ну и на длинке например включен тоже fast-leave, а потоки он не обрубает нифига всё-равно...

Добрый день, народ!! )) Столкнулся с одной интересной проблемой, но не могу осилить ) Имеем вот такую схему вкраце. Каталист имеет связь с поставщиком по PIM для мультика. А MikroTik-CCR1036 во vlan450 связан с каталистом тоже и поднят PIM, и мультик дальше уже маршрутизируется в 400-ый влан, который прокинут до клиентов dlink-DGS-3120 - это свитч агрегации на объекте а qtech - это свитч доступа. На всех коммутаторах включен igmp-snooping. Проблема вся в том что между микротиками туннель всего 100 мегабит. и происходит следующее: когда клиенты начинают щелкать каналы iptv, они подписываются на большое количество мультикаст-групп. свитчи доступа qtech сразу втечение 5 секунд обрезают им потоки мультикаст ну хавают пакеты leave. А вот mikrotik-ccr1036 эти потоки не обрезает сразу, даже если на них никто не подписан. и даже dlink их не обрезает. Идет счетчик просто на убывание 260 секунд и только если никто не ответил report в этом случае по истечению 260 сек поток обрубается, а это аж 4 минуты 20 секунд!! Почему то ни dlink ни mikrotik не реагируют на пакеты leave, не знаю должны ли они это делать правда. Ну если на длинке я нашел настройки, чтоб убавить счетчик с 260 сек например до 160, то на микротике вообще таких настроек я найти не могу. в итоге клиент например перещелкнул 20 каналов и канал между микротиками заполнился уже на 80 мегабит и этот поток идет 260 секунд. Соответственно часто возникают лаги из-за этого. Нужно либо где то убавить этот таймаут на микротике, либо как-то сделать, чтоб микротик хавал leave пакеты. Но на микротике я нигде не нашел подобных настроек. для наглядности вот этот счетчик: Подскажите какие могут решения подобной проблемы? может я что-то ни там ищу? может чего-то не догоняю ) fast leave на длинке включен... не знаю даже что делать...

заметил, что после перехода на нстрим начали происходить кратковременные разрывы в логах пишет вот что со стороны station wds: 16:57:35 wireless,info D4:CA:6D:12:F6:72@wlan2-iptv: lost connection, not polled for too long 16:57:35 wireless,info D4:CA:6D:12:F6:72@wlan2-iptv established connection on 5330, SSID MikroTik2 со стороны bridge: 23:14:12 wireless,info D4:CA:6D:12:F6:B0@wlan2-iptv: disconnected, too many poll timeouts 23:14:12 wireless,info D4:CA:6D:12:F6:B0@wlan2-iptv: connected, wants WDS подскажите куда копнуть, где то надо уменьшить таймаут или отключить поллинг

и еще от себя добавлю: в моей практике с одного борда запустить 2 радио карты с нормальными параметрами получилось только в дуал нстриме все остальные попытки запустить 2 карты в полноценные независимые линки всегда упирались в падение квалити либо на одной карте либо на обоих поэтому давно уже работаю по правилу борд - линк кстати давно хотел предложить вам погасить (оключить карты) на "дата" линке и посмотреть как ведет себя линк с мультикастом. а второй линк просто простаивает? или вы туда даже радиокарточки не вставляете?

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

как обычно совет из раздела пох, не объясняя тут либо не нагружен канал, либо такая обстановка в эфире в конкретной точке..... и тут либо грузить его и будет пинг в норме, либо как сказал саб в нстреам переключить спасибо, попробую на досуге переключить. там маршрутизацию надо настроить между езернетами через wlan-ы

пользуясь случаем хочу спросить про большой разброс задержек при пинге по wi-fi от чего зависит? хотелось бы стабилизовать. на rocket-M5 стабильно не больше 3ms бывает. HOST SIZE TTL TIME STATUS 192.168.214.105 1400 64 10ms 192.168.214.105 1400 64 18ms 192.168.214.105 1400 64 2ms 192.168.214.105 1400 64 11ms 192.168.214.105 1400 64 3ms 192.168.214.105 1400 64 3ms 192.168.214.105 1400 64 2ms 192.168.214.105 1400 64 2ms 192.168.214.105 1400 64 2ms 192.168.214.105 1400 64 14ms 192.168.214.105 1400 64 21ms 192.168.214.105 1400 64 3ms 192.168.214.105 1400 64 4ms 192.168.214.105 1400 64 23ms 192.168.214.105 1400 64 18ms 192.168.214.105 1400 64 3ms 192.168.214.105 1400 64 9ms 192.168.214.105 1400 64 3ms 192.168.214.105 1400 64 3ms 192.168.214.105 1400 64 3ms

192.168.214.104: [admin@WORK] > system resource print uptime: 3w10h45m58s version: 5.24 free-memory: 111556KiB total-memory: 127160KiB cpu: MIPS 24Kc V7.4 cpu-count: 1 cpu-frequency: 800MHz cpu-load: 17% free-hdd-space: 22360KiB total-hdd-space: 61440KiB write-sect-since-reboot: 246761 write-sect-total: 276357 bad-blocks: 0.7% architecture-name: mipsbe board-name: RB433AH platform: MikroTik 192.168.214.105: [admin@MikroTik] > sys resource print uptime: 2w6d7h41m36s version: 5.24 free-memory: 111980KiB total-memory: 127160KiB cpu: MIPS 24Kc V7.4 cpu-count: 1 cpu-frequency: 800MHz cpu-load: 18% free-hdd-space: 21824KiB total-hdd-space: 61440KiB write-sect-since-reboot: 234291 write-sect-total: 416417 bad-blocks: 1% architecture-name: mipsbe board-name: RB433AH platform: MikroTik

ну блин я конечно тоже склонен винить свитч, но это же нереал какой то. мы уже заменили этот свитч первым делом. как вариант, конечно можно попробовать воткнуть приставку сразу в микротик. проблема в том, что я не смогу нагрузить канал до 10 мегабит в этом случае... так то у меня там есть пара клиентов еще на других свитчах доступа которые нагружают канал. ну когда кончатся все варианты и удасться туда монтажника загнать, я попробую конечно исключить и свитч агрегации dlink-3200 и пачкорд заменить и порт поменять на свитче если что. :D

это читал, но по-моему это другой случай. там рассматривается вариант, когда у клиента стоит домашний роутер ввиде микротика и он смотрит на разных устройствах разные каналы насколько я понял. суть в том что определенную мультикаст группу транслировать определенному мак-адресу. в моем случае микротики играют роль магистральных узлов. один подключен к другому и больше никого. ну для подстраховки включил функцию multicast-helper=full, картины это не изменило.

дело в том, что stb-приставка 10.40.0.75 вставлена непосредственно в dlink-3200 без всяких роутеров вообще. сделано это специально, чтоб исключить все лишние узлы в процессе выявления проблемы...

роутеры такие же стоят у нас на других объектах. там где нет микротиков, там всё ок. все STB приставки в отдельном своём 400-ом влане, больше никого там нет. коммутаторы поддержиывают igmp_snooping и он включен.

Константин. ну вот привел я всё к следующей схеме. Потери всё равно остались до 10.40.0.75 при нагрузке на ether2-10.2.2.1/24 свыше 10 мегабит. И еще раз повторюсь, до адреса 10.40.0.215 потерь нет при любой нагрузке снова. При этом я еще попробовал попингал под нагрузкой 10.40.0.75 со второго микротика с адреса 10.40.0.215. И потери были. Дело явно не в вайфай, но в чем? Неужели в свитче? или в порте ether2 на микротике? ну 10 мбит - неужели это нагрузка...

в идеале проложить EOIP тунель от линукса до STB если нет то попробуйте сделать тунель от эзернета до эзернета а не от радио до радио. у мя в тунеле бегате около 40 мбит мультикаста и картинка не сыпется так работает уже года 4 прокладывать туннель от линуха до STB - чета слишком геморно, к тому же не работать же по такой схеме со всеми приставками - по моему это слишком... а вот проложить eoip-туннель от езернета до езернета - я не понял как это можно, они же в разных сегментах, нужно бриджевать езернет интерфейсы с wlan-интерфейсами, тогда мы вернемся к предыдущей схеме, в итоге я могу между бриджами замутить eoip-туннель, но как туда мне засунуть мультикаст трафик.... возможно я чего-то не допонимаю, если возможно - объясните подробнее. сам ни чем не транслирую, мультикастовые потоки сразу берем у поставщика. я почему то уверен что с wi-fi каналом всё впорядке. вот я нагружаю его по 30 мегабит в каждую сторону без проблем можно и до 40 нагрузить в каждую сторону. при этом потерь нет. # ping 10.40.0.75 -s 1400 -f -c 10000 PING 10.40.0.75 (10.40.0.75) 1400(1428) bytes of data. --- 10.40.0.75 ping statistics --- 10000 packets transmitted, 10000 received, 0% packet loss, time 83169ms rtt min/avg/max/mdev = 3.904/9.151/66.289/5.314 ms, pipe 5, ipg/ewma 8.317/8.192 ms потери появляются, похоже тогда, когда нагружен интерфейс ether2 свыше 10 мбит....

так оно и есть, вот две мультикаст-группы внутри eoip-тунеля

Привел всё вот к такой схеме. Не знаю так ли вы мне советовали, но я понял так )) Проблема не ушла. Как я и говорил, при нагрузке больше 10 мегабит появляются потери до STB-приставок (10.40.0.75), картинка рассыпается, но нет потерь при любой нагрузке до адреса 10.40.0.215 Мне кажется проблема не в wi-fi...

Добрый день. Уважаемые знатоки )) помогите решить проблему, уже голову сломал. имеем вот такую схему: Гоним мультикаст через микротики, между ними Wi-Fi, мультикаст через 2 линк (между wlan2 и wlan2) Между микротиками (которые 433) связь примерно так устроена: 192.168.215.104: 192.168.215.105: Проблема в том, что начинает картинка рассыпаться и звук лагает временами. Диагностика привела вот к следующим результатам: С тачки с линуха (10.40.0.1) пингаю STB-приставки в частности 10.40.0.75, которая вставлена непосредственно в коммутатор агрегации 192.168.214.84 # ping 10.40.0.75 -s 1400 -f -c 10000 PING 10.40.0.75 (10.40.0.75) 1400(1428) bytes of data. .......... --- 10.40.0.75 ping statistics --- 10000 packets transmitted, 9990 received, 0% packet loss, time 78144ms rtt min/avg/max/mdev = 3.229/8.578/63.924/5.345 ms, pipe 6, ipg/ewma 7.815/6.385 ms и до приставки есть потери, собственно уверен, что это и вызывает рассыпание картинки. Но! интересный момент заключается в следующем, что эти потери появляются только если поток мультикастовый превышает 10mbit... Если канал нагружен меньше 10 мбит то IPTV не лагает и потерь нет до приставок. А самое интересное, что я также проверяю связь до второго микротика (10.40.0.215) # ping 10.40.0.215 -s 1400 -f -c 10000 PING 10.40.0.215 (10.40.0.215) 1400(1428) bytes of data. --- 10.40.0.215 ping statistics --- 10000 packets transmitted, 10000 received, 0% packet loss, time 58269ms rtt min/avg/max/mdev = 2.666/6.157/63.558/4.537 ms, pipe 5, ipg/ewma 5.827/8.934 ms И до него потерь не бывает независимо от того, как загружен wi-fi. Коммутатор 192.168.214.84 уже заменили. проблема осталась. Такое ощущение, что проблема в микротике в интерфейсах ethernet как будто они не справляются с таким потоком. Подскажите плиз куда копнуть.

народ подскажите, у нас стоят quidway s2300, но они жесть какие тормозные. в том плане что если пингуешь их то они отвечают не сразу, а через 3-4 сек. в нагиосе из-за этого часто бывают красными, хотя по сути доступны, CLI подтормаживает из-за этого немного, и запросы по SNMP тоже предполагаю из-за этого медленно работают. Кто-то писал что это защита от атак от ddos, может кто нибудь знает как отключить?

AciDSAS говорит, что пробовал собирал модули версий 3.2.10 & 3.3.6 3.3.6 - это последняя версия драйвера с intel.com на данный момент да и у меня, щас глянул, тоже 3.3.6 стоит AciDSAS, тут советовали обновить ядро и ethtool, после чего попробовать включить/отключить аппаратную поддержку vlan. есть возможность обновить ядро? я что-то ссу на рабочей тачке удаленно обновлять ядро ))