McDewey

Multi-vendor documentation library · semantic search · MCP endpoint at /mcp

Page 5

↗ View in doc context
page
5
source
catalyst-6500/series/legacy-tech-doc-10559/legacy-tech-doc-10559.md
chunk_id
catalyst-6500::series::legacy-tech-doc-10559::legacy-tech-doc-10559::4

In order for a computer to support SSM, it must support IGMPv3. Relatively few OS, however, support IGMPv3. Windows XP supports IGMPv3, and there are IGMPv3 support patches available for FreeBSD and Linux. Administrators must distinguish between IGMPv3 support at the router level and IGMPv3 snooping at the switch level. They are two different features. Support of IGMPv3 on Catalyst Switches (L2) The Catalyst 6000 running hybrid mode software (CatOS on Supervisor and Cisco IOS® Software on MSFC) officially supports IGMPv3 snooping starting in version 7.5(1). G In versions prior to 7.5(1), the Catalyst 6000 switch did not have official support for IGMPv3, but it should normally be able to handle IGMPv3 packets. G The Catalyst 6000 running Integrated IOS Software supports IGMPv3 at the router level (L3 interface) starting in Version 12.1(8a)E. G The Catalyst 4000 only supports IGMPv3 at the router level on the Supervisor III and IV. It does not support IGMPv3 snooping. G Support of IGMPv3 on Cisco Routers (L3) IGMPv3 is supported on all platforms running Cisco IOS® software Release 12.1(5)T and later releases. Caveats When a switch is running IGMP snooping, it intercepts the IGMP packets and populates the static Layer 2 (L2) forwarding table based on the content of the intercepted packets. When there are IGMPv1 or v2 hosts on the network, the switch reads the IGMP Joins and Leaves to determine which hosts wants to receive which multicast stream, or stop receiving the multicast stream. IGMPv3 is more complicated, because it uses not only the group address (multicast address), but also the sources from which traffic is expected. Apart from the Catalyst 6000 switch running CatOS 7.5 or later and Native IOS Version 12.1(8a)E or later, no other switches are currently able to effectively snoop those packets and build a forwarding table based on this information. Therefore, IGMP snooping should be turned off when there is an IGMPv3 host on the switch. When IGMP snooping is turned off, the switch cannot dynamically build a L2 forwarding table for the multicast streams. In other words, the switch floods the multicast streams. When IGMP snooping is disabled, one solution is to manually configure multicast dynamic Content-Addressable Memory (CAM) entries in order to avoid flooding the subnet with multicast traffic. This is an administrative burden, however, and is not a dynamic solution. When a client no longer wants to receive the traffic, the CAM entry is not removed from the switch (unless by manual intervention), so network traffic is still addressed to the host. Also, when using IGMPv3 in the network, switches using CGMP work normally apart from the fact that CGMP Fastleave does not work. If CGMP Fastleave is needed, it is best to revert to IGMPv2. The outstanding platform-specific caveats can be found in the release notes for the respective switches.