Доброго времени.

Уже очень давно наблюдаю интересные моменты в поведении сабжа.
Вариант 1 (старое наблюдение):
Имеем DGS-3627G. В этот DGS входит по 10Г порту VLAN X с мультикастом. Этот же влан уходит дальше через LACP транк. На самом коммутаторе поднят на этом ВЛАН ipif, включен PIM и мультикаст ходит к абонентикам. Стоит только произвести любые манипуляции с lacp транком - по ту сторону транка мультикаст пропадает частично или полностью. Делаем на "транзитном" DGS dis pim/en pim и все возвращается на круги своя.

Вариант 2 (свежее наблюдение):
Имеем коммутатор DGS-3627G. На него на входе по 10Г порту приходит VLAN X с мультикастом. Тут же висит ipif, на нем pim и так далее. Берем ВЛАН X и добавляем или убираем в/из него порт (не вход, любой другой порт, не важно Link UP там или Link DOWN). На входящем порту начинается знатный multicast drop и мультикаст до абонентов уже не едет. dis pim/en pim - все возвращается на круги своя.

Дополнительное наблюдение к варианту 2:
Перед описанным в варианте 2 DGS-3627G стоит другой DGS-3627G. Назовем их DGS-3627G-1 - конечный, DGS-3627G-2 - промежуточный. На DGS-3627G-2 приходит по 10Г мультикаст, на нем ipif, pim и так далее, а дальше мультикаст в том же ВЛАН Х через другой 10Г порт уходит на DGS-3627G-1. При этом ВЛАНы на входе DGS-3627G-2 уходят в DGS-3627G-1 те же самые, за минусом лишних. То есть ничего того (лишнего), что не приходило бы в DGS-3627G-2 не идет до DGS-3627G-1. Мониторим ошибки на входящих портах DGS-3627G-1 и DGS-3627G-2. На DGS-3627G-2 (Транзитном) на входе дроп multicast около 3-х пакетов в секунду. При этом уже на DGS-3627G-1 (конечном) дропов стабильно около 1200 пакетиков в секунду.

Вариант 3 (связанный с Вариантом 2):
Сразу за оговоренным в варианте 2 DGS вешаю DES и из него ISM вывожу на DGS. Запускаю анализатор мультикаста (ts-потока) и (не сказать часто - когда раз в десяток полтора минут, а раз и реже - в часах может измерятся интервал) идут потери мультикаст пакетов. Причем стабильно эти потери есть. Беру VLAN X - прогоняю его то тестового порта, бросаю его туда тагированным вместо ISM VLAN и начинаю снова анализировать мультикаст. И тут случается чудо - дропов нет. Вывод: на этапе маршрутизации мультикаста сквозь DGS по какой-то причине при невыясненных обстоятельствах теряются пакетики (не в те ли 1200 дропов они попадают, о которых речь шла выше?).

Больше всего интересует вопрос - что делать с вариантом 3? Стоит заметить - такая ситуация наблюдается не везде. Прошивку в рамках эксперимента обновил до 2.84.B48 (до этого там была 2.84.B40), но ситуация не изменилась.

Варианты 1-2 также интересны. Не очень красиво на каждое телодвижение с коммутатором дергать pim.

Дополнительная информация:
1. Используется PIM-SM
2. В арпах 2853 записей. В пиках не более 3500. В любом случае более чем в два раза меньше заявленных 8000.
3. В fdb - 1871
4. arp agin time 14400
5. fdb aging time 300
6. System Uptime : 2 days, 13 hours, 9 minutes, 44 seconds
7. За время аптайма:
#show error ports 25
Command: show error ports 25


Port number : 25
RX Frames TX Frames
--------- ---------
CRC Error 0 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 0 Late Collision 0
Fragment 0 Excessive Collision 0
Jabber 0 Single Collision 0
Drop Pkts 3112505227 Collision 0
Symbol Error 0
Buffer Full Drop 631288
ACL Drop 0
Multicast Drop 365649357
VLAN Ingress Drop 11

Вопрос дропов на входе снимается созданием статичной подписки на все имеющиеся группы на одном из целевых PIM ipif. Однако остаются открытыми вопросы застревания мультикаста после манипуляций с вланами и транками, а также потерь в маршрутизации.

Добрый день. Вы Multicast трафик входящий приоритизируете или он уже с какими-то метками приоритета приходит?

P.S.: Проблемы ещё могут быть из-за того, что fdb записей меньше чем arp записей.

_________________
С уважением,
Бигаров Руслан.

На коммутаторе присутствуют ACL:
create access_profile profile_id 1 ip destination_ip_mask 240.0.0.0 udp
config access_profile profile_id 1 add access_id 1 ip destination_ip 224.0.0.0 udp port 1-27 permit priority 7 replace_priority rx_rate no_limit
create access_profile profile_id 10 ip dscp
config access_profile profile_id 10 add access_id 1 ip dscp 46 port 25-27 permit priority 5 replace_priority rx_rate no_limit

На коммутаторе, который для этого RP:
create access_profile profile_id 10 ip destination_ip_mask 255.255.255.0 udp
config access_profile profile_id 10 add access_id 1 ip destination_ip 238.1.1.0 udp port 1-27 permit priority 5 replace_priority replace_dscp 46 rx_rate no_limit

Есть некоторое подозрение на такой момент: на коммутаторе есть пара загруженных портов, которые в некоторых пиках вызывают на входе buffer full drop, однако на тех портах отсутствует абонентский трафик и мультикаст (другие VLAN). Может ли это влиять на прохождение мультикаста в другие порты?

А также не ясно насчет телодвижение с VLAN/Link agg и пропажей мультикаста с PIM.

PS: Как меньшее число записей fdb в сравнении с arp может влиять на потери мультикаста? Даже если исходить из дефолта - fdb - 5 минут, arp - 20 минут. То есть на 15 минут отсутствия мака в fdb будут потери?

Нет, так как коммутационная фабрика с неблокирующей архитектурой.



При VLAN/Link agg нужно проверить, чтобы настройки на всех портах участвующих в группе были одинаковы. Если пропали все записи ipmroute, то нужно проверить маршрут до RP, next hop должен быть из подсети интерфейса, на котором включен PIM.



Потери могут быть как побочный эффект. Например, приходит трафик для определённого хоста, arp запись есть, а fdb нет, это означает, что коммутатор будет его рассылать на все порты, которые находятся в VLAN-е данного хоста.

_________________
С уважением,
Бигаров Руслан.

При Link aggregation - я даже порты не смогу собрать в группу, если не будут одинаковые настройки. Этот вариант не подходит. А что касается VLAN - на коммутаторе вообще нет Link agg, но стоит только влан с мультикастом добавить или убрать на любые порты (кроме входящего, конечно) - сразу на входе начинается грозный multicast drop до dis pim/en pim - после него прекращается.



Мысль применима только к ситуации, если порты перегружены. Да и мультикаст имеет приоритет выше.

В этом VLAN-е коммутатор получает Multicast от RP? Или это VLAN который спускает Multicast трафик вниз в ISM VLAN на доступе?

_________________
С уважением,
Бигаров Руслан.