IGMP rình mò và địa chỉ multicast liên kết cục bộ

Tôi có một mạng có nhiều thiết bị gửi dữ liệu tới 224.0.0.225 trên Vlan trải rộng trên nhiều thiết bị chuyển mạch. Mỗi thiết bị (aprox 12 trong số chúng) đang gửi dữ liệu báo cáo với tốc độ khoảng 500-600 kbps. Mỗi cổng trên Vlan, cho dù người nhận có gửi tham gia hay không, sẽ bị ngập với khoảng 6mbps lưu lượng phát đa hướng.

IGMP snooping được bật trên tất cả các thiết bị chuyển mạch và Vlan cục bộ.
pim spzzy-mode được cấu hình trên cổng mrouter / default.

Nếu tôi thực hiện một show ip igmp snooping groupscông tắc, không có mục nào trong bảng rình mò.

Tôi biết 224.0.0.1 - 224.0.0.255 nằm trong phạm vi IP Multicast dành riêng cho liên kết cục bộ có nghĩa là bộ định tuyến sẽ không chuyển tiếp các gói trong phạm vi này. Những phạm vi này cũng được sử dụng để nói chuyện giao thức định tuyến. ví dụ: EIGRP, OSPF, HSRP ...

Tôi có hai câu hỏi:
1) Tôi nghĩ câu trả lời là CÓ - cho 224.0.0.1 224.0.0.255 ... IGMPv2 có bỏ qua phạm vi này để rình mò không và công tắc có chuyển tiếp điều này sang tất cả các cổng không?
2) Có cách nào để buộc IGMP theo dõi lưu lượng phát đa hướng này và chỉ gửi nó đến các cổng yêu cầu tham gia IGMP không?

Tôi có cảm giác đây là một trong những trường hợp mà ứng dụng / lập trình viên cần thiết kế các thiết bị và ứng dụng của họ để tôn trọng các mạng không tiêu dùng có thể mở rộng. Do đó, họ nên sử dụng một địa chỉ multicast trong phạm vi 239.0.0.0/8.

Tôi đã tiếp tục tìm hiểu trên mạng .... và tôi nghĩ rằng tôi đã trả lời câu hỏi của riêng mình.
Bây giờ tôi cần quay lại với chủ sở hữu / nhà phát triển ứng dụng / thiết bị và xem những gì chúng tôi có thể làm hoặc tiếp tục khóa các thiết bị này xuống Vlan của riêng họ.

Hãy để lại ý kiến ​​hoặc câu trả lời với bất kỳ lời khuyên nào.

RFC 4541 2.1.2 :

1) Các gói có địa chỉ IP đích bên ngoài 224.0.0.X không phải là IGMP nên được chuyển tiếp theo các bảng thành viên cổng dựa trên nhóm và cũng phải được chuyển tiếp trên các cổng của bộ định tuyến.

  This is the main IGMP snooping functionality for the data path.
  One approach that an implementation could take would be to
  maintain separate membership and multicast router tables in
  software and then "merge" these tables into a forwarding cache.

2) Các gói có địa chỉ IP đích (DIP) trong phạm vi 224.0.0.X không phải là IGMP phải được chuyển tiếp trên tất cả các cổng.

  This recommendation is based on the fact that many host systems do
  not send Join IP multicast addresses in this range before sending
  or listening to IP multicast packets.  Furthermore, since the
  224.0.0.X address range is defined as link-local (not to be
  routed), it seems unnecessary to keep the state for each address
  in this range.  Additionally, some routers operate in the
  224.0.0.X address range without issuing IGMP Joins, and these
  applications would break if the switch were to prune them due to
  not having seen a Join Group message from the router.

Có một cảnh báo khác: Tùy thuộc vào nền tảng, công tắc sẽ chuyển tất cả phát đa hướng liên kết cục bộ đến CPU. Điều này bao gồm lưu lượng truy cập OSPF.

Tôi nhận thấy điều này trên Ciscos Catalyst 4500 sẽ gửi tất cả lưu lượng 224.0.0.x đến CPU. Khi CPU bận, nó sẽ bỏ các gói, bao gồm các gói OSPF của bạn. Vui vẻ gỡ lỗi tại sao (các) phiên OSPF của bạn giảm.

Ngoài ra, tắt igmp rình mò trên nền tảng không có ích. Tại một số thời điểm, Cisco nhận thấy rằng đây có lẽ không phải là ý tưởng tốt nhất và đã giới thiệu lệnh:

access-list hardware capture mode vlan

Điều này sẽ bắc cầu cho các gói multicast trong phần cứng.

Xem http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.2/52sg/configuration/guide/secure.html#wp1128851 để biết chi tiết