survivor Posted September 25, 2014 (edited) · Report post Доброго дня, Фигня какая-то происходит, посоветуйте чего-нибудь. Простая вроде конфигурация. Сеть - extended star, каждый лучик - отдельный влан, на концах - точки присутствия с абонентами. В центральном офисе (подключенном к звезде отдельным вланом) точка рандеву, рядом со источником потока. В сторону аплинка на точках: ip pim sparse-mode В сторону абонентских вланов: ip pim passive Настройки pim'а: ip pim rp-address <IP-RP> <ACL-WITH-GROUPS> override ip pim spt-threshold infinity Все работает как надо. Абоненты подписываются, смотрят, отписываются. Ничего лишнего нигде не ходит. Но на графиках загрузки линков, время от времени появляются чудовищные всплески траффика, длительностью до получаса, в несколько сотен мегабит (полный поток iptv - почти гигабит). В этот же момент графики mcast pps показывают пару десятков тысяч pps. Направление траффика - в сторону точек присутствия. Самое веселое - на точках присутствия графики показывают только входящий всплеск, к абонентам же ничего не пытается уйти на сумасшедшей скорости. Как будто траффик в черную дыру уходит... или каталист обрел разум и сам смотрит каналы )) хотя нет - cpu никак не поднимается в этот момент. Такая ситуация по всей сети, по всем точкам, никакой связи ни по времени, ни по направлениям. Периодичность - примерно раз в сутки. Я чего-то не донастроил? Баг иоса? Что это может быть? Edited September 25, 2014 by survivor Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted September 25, 2014 · Report post В момент всплеска нужно сравнить таблицу mroute на L3-multicast устройстве с таблице igmp-snooping/mvr в L2 сегменте Скорее всего, какой-нибудь абонент запрашивает кучу групп, а отписка не доходит или не обрабатывается на L3 устройстве, как следствие мультикаст сыпется в L2 сегмент, но дропается. Вообщем, я бы отснифал всю сигнализацию в момент проблемы, чтоб посмотреть что реально происходит Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 25, 2014 · Report post Ещё может быть лже quirrer который запрашивает на себя все что есть каналы. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 25, 2014 · Report post Скорее всего, какой-нибудь абонент запрашивает кучу групп, а отписка не доходит Ещё может быть лже quirrer который запрашивает на себя все что есть каналы Да, все верно, такое может быть. Только почему абонентские графики чистые?! Никаких всплесков, обычный траффик... Каталист то должен был отправить все эти 100-150 мегабит этому вредному абоненту. Это вводит в тупик. Кроме того, такое по всей сети, в разное время, но как минимум раз в сутки. И не чаще. Или у меня появилась целая шайка недоброжелателей равномерно рассеяных по всему городу? Причем зловредничающих исподтишка по чуть-чуть :) я бы отснифал всю сигнализацию в момент проблемы, чтоб посмотреть что реально происходит Пытаюсь, пока не могу отловить этот момент. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 25, 2014 · Report post Сорри, похоже все-таки к абонентам льется лишний траффик. Нашел парочку, цифры правда поменьше, но порядок тот же. Видимо все-таки кто-то не отписывается, буду ловить Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 25, 2014 (edited) · Report post Не уверен что оно... слишком кратковременно... Но данные собрал: #sh ip mr Outgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 239.XXX.XXX.102), 00:00:33/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:33/00:02:26, H (*, 239.XXX.XXX.97), 00:02:05/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:05/00:00:54, H (*, 239.XXX.XXX.124), 00:01:54/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:01:54/00:01:05, H (*, 239.XXX.XXX.125), 00:01:57/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:01:57/00:01:02, H (*, 239.XXX.XXX.127), 00:02:16/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:16/00:00:43, H (*, 239.XXX.XXX.122), 00:00:30/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:30/00:02:29, H (*, 239.XXX.XXX.119), 00:02:22/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:22/00:00:37, H (*, 239.XXX.XXX.79), 00:00:13/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:13/00:02:46, H (*, 239.XXX.XXX.64), 00:03:04/00:02:57, RP 10.100.1.9, flags: SP Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Null (*, 239.XXX.XXX.89), 00:00:37/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:37/00:02:22, H (*, 239.XXX.XXX.86), 00:00:22/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:22/00:02:37, H (*, 239.XXX.XXX.85), 00:00:27/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:27/00:02:32, H (*, 239.XXX.XXX.82), 00:00:17/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:17/00:02:42, H (*, 239.XXX.XXX.83), 00:00:03/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:03/00:02:56, H (*, 239.XXX.XXX.37), 00:03:02/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:03:02/00:00:10, H (*, 239.XXX.XXX.36), 00:02:02/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:02/00:00:57, H (*, 239.XXX.XXX.38), 00:00:11/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:11/00:02:48, H (*, 239.XXX.XXX.63), 00:01:51/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:01:51/00:01:26, H (*, 239.XXX.XXX.8), 00:02:50/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:50/00:00:14, H (*, 239.XXX.XXX.13), 00:03:07/00:02:55, RP 10.100.1.9, flags: SP Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Null (*, 239.XXX.XXX.5), 00:40:16/00:02:27, RP 10.100.1.9, flags: SP Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Null (*, 239.XXX.XXX.209), 21:49:09/00:03:29, RP 10.100.1.9, flags: S Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan632, Forward/Sparse, 21:49:09/00:02:45, H (*, 239.XXX.XXX.162), 00:02:13/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:13/00:00:46, H (*, 239.XXX.XXX.164), 00:02:34/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:34/00:00:26, H (*, 239.XXX.XXX.171), 00:02:26/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:26/00:00:33, H (*, 239.XXX.XXX.139), 00:00:43/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:44/00:02:15, H (*, 239.XXX.XXX.140), 00:00:59/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:00:59/00:02:00, H (*, 239.XXX.XXX.146), 00:02:40/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:40/00:00:19, H (*, 239.XXX.XXX.145), 00:02:10/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:10/00:00:49, H (*, 239.XXX.XXX.149), 00:02:20/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:20/00:00:39, H (*, 239.XXX.XXX.157), 00:02:43/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan638, RPF nbr 10.200.38.1 Outgoing interface list: Vlan504, Forward/Sparse-Dense, 00:02:43/00:00:16, H (*, 224.0.1.40), 20w1d/00:02:13, RP 0.0.0.0, flags: DPL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null При этом: #sh ip igmp snooping groups Vlan Group Version Port List ------------------------------------------------------------ 504 239.XXX.XXX.83 v2 Fa0/4 504 239.255.255.250 v2 Fa0/4 632 224.0.1.40 v2 Gi0/2 Странно, в снупинге каталист знает о подписке только на один канал 239.XXX.XXX.83 с порта Fa0/4 А на каталист приходят куча каналов, которые хотят уйти в int vlan504 который связан с портом Fa0/4 На дсламе, который сидит на Fa0/4 все норм - один абонент, одна подписка. Похоже проблема у меня... Edited September 25, 2014 by survivor Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 25, 2014 (edited) · Report post s.lobanov В момент всплеска нужно сравнить таблицу mroute на L3-multicast устройстве с таблице igmp-snooping/mvr в L2 сегменте Похоже что у меня L3 mroute сильно отстает от igmp-snooping'а (в смысле - mroute гораздо больше). Кстати, физически это одна железка. Если я правильно понимаю, тут может помочь тюнинг "ip igmp query-max-response-time", который по умолчанию 10 секунд. Edited September 25, 2014 by survivor Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 25, 2014 · Report post А по pim'у у вас нейборов много? на них тихо? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 25, 2014 (edited) · Report post по pim'у только один neighbor - аплинк в редких случаях два (если это транзитная точка) Edited September 25, 2014 by survivor Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 25, 2014 · Report post Когда это транзитная точка на 3м свиче нет всплеска? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
uk2558 Posted September 25, 2014 · Report post Fast leave везде включен? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Azamat Posted September 25, 2014 · Report post Исходя из нашего опыта, похоже, что на каталистах не корректно (от слова совсем) работает функционал блокировки tcn flood. При этом стандартное поведение коммутатора при холодной перезагрузке таково: в сторону вышестоящего коммутатора летит topology change notification, вышестоящий в сторону нижестоящего транка, на котором есть mvr type source начинает лить ВЕСЬ мультикаст, который присутствует в этом месте. В течение 3 циклов report блокировка tcn flood-а должна отсечь ненужный мультикаст, но ... как правило это нихрена не пашет. В 90 процентах случаях мультикаст прекращает литься в нижестоящий свич в течение 6 мин, например если нижестоящий коммутатор подключен на 100 мбит/с , а на узле присутствуют порядка 200-300 мбит мультикаста (у нас гораздо больше), то на 6 мин пинг до ребутнувшегося (например по свету) коммутатора растет до 55 мс с большими потерями и невозможностью достучаться до консоли. В 10 проц. случаев этот процесс залипает и может литься неограниченно долго. При этом этот же мультикаст начинают получать десятки коммутаторов по всей округе, у нас целый месяц заняло допереть до решения. Характерно следующее (опять же, если сеть построена на каталистах) - на ВЫШЕСТОЯЩЕМ коммутаторе вывод команды show ip igmp snooping mrouter показывает помимо стандартного порта, откуда должен прилетать честный мультикаст еще и порт, к которому подключены сам "больной " коммут., а также несколько пришедших прицепом. Вот страндартный правильный вывод на вышестоящем коммутаторе: Vlan ports ---- ----- 970 Fa0/24(dynamic) Когда возникает вышеописанная проблема, то в этом списке появляются через запятую все порты, в которые льется тонны мультикаста. В идеале - 3 цикла igmp report, в реале - 6 мин, т.к. эта команда не работает: no ip igmp snooping tcn flood. А когда карма жопой - тогда печалька. Но, решение есть, очень не интуитивное. На графике 1 - в одном из микрорайонов одновремено сначала по свету были выключены порядка 20 домов, потом так же одновременно включили. На 4 домах сложилась вышеописанная ситуация, что привело на вышестоящем узле к приведенному графику. Коммутаторы были только установлены и еще не "привиты" от этой болячки, на остальных всплесков не было. На графике 2 - эта ситуация со стороны порта коммутатора, к которому оказался подключен один из "больных" домов. Но даже на не "привитых" коммутаторах в 90 проц. случаях всплеск должен был длиться 6 мин. На графиках просто карма была жопой и трафик лился часа 3, noc проспал и не сообщил. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 26, 2014 · Report post Azamat Спасибо большое за такой развернутый ответ... честно говоря потрясен... Но, решение есть, очень не интуитивное. а что за решение то? uk2558 Fast leave везде включен? вы про IGMPv2 immediate leave? Нет, к сожалению, везде выключен, так как на одном порту каталиста сидят сразу много (через дслам) клиентов. Butch3r Когда это транзитная точка на 3м свиче нет всплеска? Есть. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 26, 2014 · Report post Butch3r Цитата Когда это транзитная точка на 3м свиче нет всплеска? Есть. А на нём адресатов мультикаста нет? Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
White_Alex Posted September 26, 2014 · Report post а что за решение то? +1 поделитесь, правда интересно Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 26, 2014 (edited) · Report post А на нём адресатов мультикаста нет? судя по графикам - нет, сложно сказать точно из того что видел своими глазами на железке: на каталисте sh ip mroute ИНОГДА показывает дохрена маршрутов (*,G) в интерфейс Vlan N, а sh ip igmp snooping group показывает только одну!!! мультикаст группу на физическом интерфейсе (абонентском) в соответствующем влане. Через какое-то время все нормализуется. Edited September 26, 2014 by survivor Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted September 26, 2014 · Report post на каталисте sh ip mroute ИНОГДА показывает дохрена маршрутов (*,G) в интерфейс Vlan N, а sh ip igmp snooping group показывает только одну!!! мультикаст группу на физическом интерфейсе (абонентском) в соответствующем влане. Через какое-то время все нормализуется. ну как я и говорил. теперь отсниферите сигналлинг и попробуйте понять почему это происходит P.S. Ну и вопрос немного в сторону. Зачем "ip pim spt-threshold infinity" нужно? чем вас классический вариант с переключением на (S,G) не устраивает? Извиняюсь за оффтоп, просто интересно. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Butch3r Posted September 26, 2014 · Report post А свичи между собой /30 подключены или в одной сети/одном влане? Просто у меня схема такая: /24 для свичей, на них всех PIM. Так вот если на любом одном свиче кто-то смотрит канал он тут же появляется на всех свичах. И как раз в igmp group их 0 а в show igmp_snooping forwarding есть все каналы которые смотрят на всех свичах Чтоб этого не было нужен pim snooping Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 26, 2014 · Report post ну как я и говорил. теперь отсниферите сигналлинг и попробуйте понять почему это происходит собираю лабу на столе... Зачем "ip pim spt-threshold infinity" нужно? ну... у меня один источник потока, постоянная точка рандеву, резервных каналов до нее от точек присутствия нет... Так вот если на любом одном свиче кто-то смотрит канал он тут же появляется на всех свичах знакомая ситуация :) сталкивался в этом при первоначальном внедрении iptv. Сейчас все свичи в разных вланах. И как раз в igmp group их 0 а в show igmp_snooping forwarding есть все каналы которые смотрят на всех свичах нет, вы не поняли. свич на котором много (*,G) в sh ip mr и один поток в sh ip igmp snooping - это один и тот же свич. И других свичей в влане, который соединяет его с аплинком, и в котором работает pim, нету. Интересная информация поступила - нашел одного абонента, который создал всплеск на час в сотню мегабит в сторону каталиста. Абонент подключен через дслам, на скорости 8 мегабит. После модема стоит MAG-250 который подключен через bridge vpi/vci. Абонент погулял по HD каналам, получил рассыпание картинки, после чего на всех каналах пошли квадратики. Перегрузка STB не помогла. Все нормализовалось только после выключения модема. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
-Ars- Posted September 26, 2014 · Report post Абонент погулял по HD каналам, получил рассыпание картинки, после чего на всех каналах пошли квадратики. Т.е. судя по описанию - отписка не прошла. Значит, либо модем, хотя и в режиме моста, не пропускает leave, либо DSLAM его игнорировал, пока линия не пересинхронизировалась. Во веселуха :( Offtopic: Чем-то схожую ситуацию я встречал, когда у клиента DSLAM IP querier за каким-то фигом был сконфигурирован на 192.168.2.1. Если к ним подключался СРЕ с таким же IP в LAN, то начинался бардак: то каналы не сбрасывались, то не подключались. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 26, 2014 · Report post Т.е. судя по описанию - отписка не прошла. Значит, либо модем, хотя и в режиме моста, не пропускает leave хорошо, а как же last member query? каталист должен был спросить смотрит ли кто-то данный канал и не получив ответа (the default leave latency for individual leaves in Cisco IOS software is 3 seconds) перестать вещать канал. Однако этого не происходило почти час! Чем-то схожую ситуацию я встречал, когда у клиента DSLAM IP querier за каким-то фигом был сконфигурирован на 192.168.2.1 Хм... #sh ip igmp snooping querier Vlan IP Address IGMP Version Port ---------------------------------------------------------------- 501 10.90.138.254 v2 Router 504 10.90.138.254 v2 Router 505 10.90.138.254 v2 Router 506 10.90.138.254 v2 Router 507 192.168.1.1 v2 Fa0/7 508 192.168.1.1 v2 Fa0/8 509 192.168.1.1 v2 Fa0/9 632 10.200.32.1 v2 Router 638 10.200.38.1 v2 Gi0/1 2208 10.10.138.8 v2 Fa0/8 10.90.138.254 - это IP самого каталиста 192.168.1.1 - у меня таких адресов в сети нет 10.200.32.1 - IP интерфейса Vlan в направлении следующего каталиста в цепочке 10.200.38.1 - IP аплинк каталиста 10.10.138.8 - IP одного из дсламов Дсламы в основном сконфигурены в режиме igmp proxy, чтобы у меня на каталисте подписывались на каналы не абоненты, а сам дслам. В этом случае - в качестве IP подписчика я вижу не непонятные 192.168.... адреса модемов, а знакомые адреса дсламов. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
s.lobanov Posted September 26, 2014 · Report post кстати, на многих свитчах есть фича igmp group limit. установите всем абонентам 5. если у кого-то больше телевизоров, то в индивидуальном порядке таким повышайте лимит Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
survivor Posted September 26, 2014 (edited) · Report post s.lobanov я тоже так думал... не поможет. Вернее не помогло. Собрал схему на столе, без дслама. Поставил immediate leave. Подключил STB. Когда абонент смотрит один канал - такая ситуация: Switch#sh ip mr (*, 239.XXX.XXX.164), 02:15:51/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 02:15:51/00:02:11, H Switch#sh ip igmp snooping groups Vlan Group Version Port List ------------------------------------------------------------ 59 239.XXX.XXX.164 v2 Fa0/24 Стоит немного побегать по каналам: Switch#sh ip igmp snooping groups Vlan Group Version Port List ------------------------------------------------------------ 59 239.XXX.XXX.174 v2 Fa0/24 Switch#sh ip mr (*, 239.XXX.XXX.160), 00:00:06/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 00:00:06/00:02:53, H (*, 239.XXX.XXX.164), 02:16:51/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 02:16:52/00:02:08, H (*, 239.XXX.XXX.170), 00:00:08/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 00:00:08/00:02:51, H (*, 239.XXX.XXX.173), 00:00:08/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 00:00:08/00:02:51, H (*, 239.XXX.XXX.174), 00:00:06/00:02:59, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 00:00:06/00:02:53, H и т.д. ... через некоторое время становится так: Switch#sh ip igmp snooping groups Vlan Group Version Port List ------------------------------------------------------------ 59 239.XXX.XXX.174 v2 Fa0/24 Switch#sh ip mr (*, 239.XXX.XXX.160), 00:04:26/00:01:34, RP 10.100.1.9, flags: SP Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Null (*, 239.XXX.XXX.164), 02:21:11/00:00:50, RP 10.100.1.9, flags: SP Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Null (*, 239.XXX.XXX.170), 00:04:27/00:01:34, RP 10.100.1.9, flags: SP Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Null (*, 239.XXX.XXX.173), 00:04:28/00:01:32, RP 10.100.1.9, flags: SP Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Null и т.д. ... При этом к абоненту идет нормальный траффик, а с аплинка к каталисту значительно повышенный. Зачем? Чтобы каталист отправил его в Null: Outgoing interface list: Null Через еще какое-то время становится так: Switch#sh ip igmp snooping groups Vlan Group Version Port List ------------------------------------------------------------ 59 239.XXX.XXX.174 v2 Fa0/24 Switch#sh ip mr (*, 239.XXX.XXX.174), 00:08:58/00:02:58, RP 10.100.1.9, flags: SC Incoming interface: Vlan55, RPF nbr 10.112.55.9 Outgoing interface list: Vlan59, Forward/Sparse-Dense, 00:08:58/00:02:16, H Т.е. - нормально Сейчас курю дебаги.... Edited September 26, 2014 by survivor Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
nnm Posted September 26, 2014 · Report post flags: SP - по идее должно означать, что Catalyst отписался от данной группы по PIM-у. Хорошо-бы понять, как выглядит в этот момент show ip mroute на upstream-устройстве. Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...
Azamat Posted September 26, 2014 (edited) · Report post immediate leave можно ставить только у абонента на порту и то если только 1 STB . Иначе если с порта льется мультикаст-группа сразу на несколько подписчиков ("Время" на ОРТ например смотрят семей 200) , то при отписке одного из них - трафик в группу сразу прекратится и канал погаснет сразу у всех, не надолго - до след. репорта от живого абонента. В обычном режиме при получении leave коммутатор сначала опросит нижестоящих подписчиков на предмет подписки на эту же группу, только потом если не будет репорта снизу - отключит трафик в группу. Edited September 26, 2014 by Azamat Вставить ник Quote Ответить с цитированием Share this post Link to post Share on other sites More sharing options...