Перейти к содержимому
Калькуляторы

непонятные всплески мультикаст траффика

Доброго дня,

Фигня какая-то происходит, посоветуйте чего-нибудь.

 

Простая вроде конфигурация. Сеть - 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 никак не поднимается в этот момент.

 

Такая ситуация по всей сети, по всем точкам, никакой связи ни по времени, ни по направлениям. Периодичность - примерно раз в сутки.

 

Я чего-то не донастроил? Баг иоса? Что это может быть?

post-61064-044865900 1411637263_thumb.jpg

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В момент всплеска нужно сравнить таблицу mroute на L3-multicast устройстве с таблице igmp-snooping/mvr в L2 сегменте

 

Скорее всего, какой-нибудь абонент запрашивает кучу групп, а отписка не доходит или не обрабатывается на L3 устройстве, как следствие мультикаст сыпется в L2 сегмент, но дропается.

 

Вообщем, я бы отснифал всю сигнализацию в момент проблемы, чтоб посмотреть что реально происходит

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Ещё может быть лже quirrer который запрашивает на себя все что есть каналы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Скорее всего, какой-нибудь абонент запрашивает кучу групп, а отписка не доходит
Ещё может быть лже quirrer который запрашивает на себя все что есть каналы

Да, все верно, такое может быть. Только почему абонентские графики чистые?! Никаких всплесков, обычный траффик... Каталист то должен был отправить все эти 100-150 мегабит этому вредному абоненту. Это вводит в тупик.

Кроме того, такое по всей сети, в разное время, но как минимум раз в сутки. И не чаще. Или у меня появилась целая шайка недоброжелателей равномерно рассеяных по всему городу? Причем зловредничающих исподтишка по чуть-чуть :)

 

я бы отснифал всю сигнализацию в момент проблемы, чтоб посмотреть что реально происходит

Пытаюсь, пока не могу отловить этот момент.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сорри, похоже все-таки к абонентам льется лишний траффик. Нашел парочку, цифры правда поменьше, но порядок тот же.

Видимо все-таки кто-то не отписывается, буду ловить

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не уверен что оно... слишком кратковременно... Но данные собрал:

 

#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 все норм - один абонент, одна подписка. Похоже проблема у меня...

post-61064-075151500 1411643509_thumb.jpg

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

s.lobanov

В момент всплеска нужно сравнить таблицу mroute на L3-multicast устройстве с таблице igmp-snooping/mvr в L2 сегменте

 

Похоже что у меня L3 mroute сильно отстает от igmp-snooping'а (в смысле - mroute гораздо больше). Кстати, физически это одна железка.

 

Если я правильно понимаю, тут может помочь тюнинг "ip igmp query-max-response-time", который по умолчанию 10 секунд.

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А по pim'у у вас нейборов много? на них тихо?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

по pim'у только один neighbor - аплинк

в редких случаях два (если это транзитная точка)

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда это транзитная точка на 3м свиче нет всплеска?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Исходя из нашего опыта, похоже, что на каталистах не корректно (от слова совсем) работает функционал блокировки 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 проспал и не сообщил.

post-1316-012841000 1411662714_thumb.jpg

post-1316-039321400 1411663172_thumb.jpg

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Azamat

Спасибо большое за такой развернутый ответ... честно говоря потрясен...

Но, решение есть, очень не интуитивное.

а что за решение то?

 

 

uk2558

Fast leave везде включен?

вы про IGMPv2 immediate leave? Нет, к сожалению, везде выключен, так как на одном порту каталиста сидят сразу много (через дслам) клиентов.

 

Butch3r

Когда это транзитная точка на 3м свиче нет всплеска?

Есть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Butch3r

 

Цитата

Когда это транзитная точка на 3м свиче нет всплеска?

 

Есть.

А на нём адресатов мультикаста нет?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а что за решение то?

+1 поделитесь, правда интересно

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А на нём адресатов мультикаста нет?

судя по графикам - нет, сложно сказать точно

 

из того что видел своими глазами на железке:

на каталисте sh ip mroute ИНОГДА показывает дохрена маршрутов (*,G) в интерфейс Vlan N, а sh ip igmp snooping group показывает только одну!!! мультикаст группу на физическом интерфейсе (абонентском) в соответствующем влане. Через какое-то время все нормализуется.

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

на каталисте sh ip mroute ИНОГДА показывает дохрена маршрутов (*,G) в интерфейс Vlan N, а sh ip igmp snooping group показывает только одну!!! мультикаст группу на физическом интерфейсе (абонентском) в соответствующем влане. Через какое-то время все нормализуется.

ну как я и говорил. теперь отсниферите сигналлинг и попробуйте понять почему это происходит

 

P.S. Ну и вопрос немного в сторону. Зачем "ip pim spt-threshold infinity" нужно? чем вас классический вариант с переключением на (S,G) не устраивает?

Извиняюсь за оффтоп, просто интересно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А свичи между собой /30 подключены или в одной сети/одном влане? Просто у меня схема такая: /24 для свичей, на них всех PIM. Так вот если на любом одном свиче кто-то смотрит канал он тут же появляется на всех свичах. И как раз в igmp group их 0 а в show igmp_snooping forwarding есть все каналы которые смотрят на всех свичах

 

Чтоб этого не было нужен pim snooping

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ну как я и говорил. теперь отсниферите сигналлинг и попробуйте понять почему это происходит

собираю лабу на столе...

 

Зачем "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 не помогла. Все нормализовалось только после выключения модема.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Абонент погулял по HD каналам, получил рассыпание картинки, после чего на всех каналах пошли квадратики.

Т.е. судя по описанию - отписка не прошла. Значит, либо модем, хотя и в режиме моста, не пропускает leave, либо DSLAM его игнорировал, пока линия не пересинхронизировалась. Во веселуха :(

Offtopic:

Чем-то схожую ситуацию я встречал, когда у клиента DSLAM IP querier за каким-то фигом был сконфигурирован на 192.168.2.1. Если к ним подключался СРЕ с таким же IP в LAN, то начинался бардак: то каналы не сбрасывались, то не подключались.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Т.е. судя по описанию - отписка не прошла. Значит, либо модем, хотя и в режиме моста, не пропускает 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.... адреса модемов, а знакомые адреса дсламов.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

кстати, на многих свитчах есть фича igmp group limit. установите всем абонентам 5. если у кого-то больше телевизоров, то в индивидуальном порядке таким повышайте лимит

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

Т.е. - нормально

 

Сейчас курю дебаги....

Изменено пользователем survivor

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

flags: SP - по идее должно означать, что Catalyst отписался от данной группы по PIM-у. Хорошо-бы понять, как выглядит в этот момент show ip mroute на upstream-устройстве.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

immediate leave можно ставить только у абонента на порту и то если только 1 STB . Иначе если с порта льется мультикаст-группа сразу на несколько подписчиков ("Время" на ОРТ например смотрят семей 200) , то при отписке одного из них - трафик в группу сразу прекратится и канал погаснет сразу у всех, не надолго - до след. репорта от живого абонента. В обычном режиме при получении leave коммутатор сначала опросит нижестоящих подписчиков на предмет подписки на эту же группу, только потом если не будет репорта снизу - отключит трафик в группу.

Изменено пользователем Azamat

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.