Command: show fdb

Unicast MAC Address Aging Time = 300

VID VLAN Name MAC Address Port Type
---- -------------------------------- ----------------- ----- -----------------
..
Total Entries: 7581


Command: show arpentry

ARP Aging Time : 20
ARP Retry Times : 4

...

Total Entries: 17

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

БОльшая часть мак-адресов находится в qinq влане, который приходит на агрегатор, эти маки qinq влана на каждом агрегаторе светятся, а в мультикастовом влане только маки подписчиков. Как могу влиять эти маки на мультикаст?

А вывод "sh cpu port" что у Вас показывает?

DGS-3627G:admin#show cpu port
Command: show cpu port


Type PPS Total Drop
------------------- ---------- ----------- -----------
OSPFv2 0 112104 0
OSPFv3 0 0 0
RIP 0 0 0
RIPng 0 0 0
lacp 0 0 0
802.1x 0 0 0
Stacking 0 0 0
GVRP 0 0 0
stp 2 902648 0
CFM 0 0 0
LLDP 1 412052 0
CTP 14 16864936 8434872
BGP 0 0 0
DHCP 0 0 0
DHCPv6 0 0 0
erps 0 0 0
udld 0 0 0
IGMP 0 3378441 0
MLD 0 0 0
PIM IPv4 0 28025 6
PIM IPv6 0 0 0
DVMRP 0 0 0
Reserved IPv4 IPMC 96 76518969 76518969
Reserved IPv6 IPMC 44 38498060 0
Unknown IPv4 IPMC 19 196512711 196512711
Unknown IPv6 IPMC 0 0 0
ARP 0 2496 0
ICMP 0 19992 0
NDP 0 0 0
ICMPv6 0 0 0
SNTP 0 252 0
DNS 0 0 0
TFTP 0 0 0
RCP 0 0 0
TELNET 3 8232 0
VRRP 0 0 0

Да, как видно трафик, который идет на CPU небольшой. А на остальных L3 коммутаторах аналогичная картина или там в первом столбце значения больше?

Denis Evgraphov

Поясните пожалуйста что за трафик обозначается как Reserved IPv4 IPMC / Unknown IPv4 IPMC при выводе sh cpu port ?

_________________
DES-3028, DES-3526, DES-3200_28 C1/A1/B1, DES-3200_26 C1, DGS-3627G, DGS-3420-26SC A2, DGS-3420-28TC A1, DGS-3620-28SC A1-EI, DGS-3200-24 A1

В первом случае из служебного диапазона 224.0.0.0/24, во втором - весь остальной.

По поводу первого сообщения в теме. Решение проблемы, можно сказать, "в лоб" - статические подписки для каждой группы на узловых PIM-маршрутизаторах. Занимает существенную полосу между агрегаторами, но работает.

Почему тогда PIM на агрегаторах не выключите? Можно ведь за границами ядра его поднять, если уж он нужен или привыкли к нему.

Агрегация как раз и находится за пределами ядра. Имелись в виду статические подписки на группы, чтобы мультикаст наливался на площадки перманентно. А PIM как раз нужен для маршрутизации этого самого мультикаста к узлам агрегации.