- Community Home
- >
- Networking
- >
- Switching and Routing
- >
- Web and Unmanaged
- >
- IGMP Snooping failure with multiple swtiches
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-03-2014 03:39 PM
06-03-2014 03:39 PM
IGMP Snooping failure with multiple swtiches
I'm having issues with IGMP snooping between two 1910-16G switches.
Here's the network setup: Both switches are configure the same. Ports 1-8 are untagged access ports and assigned to default VLAN1, ports 9-16 are also untagged access ports and assigned to VLAN2. The optical ports 17-20 are in trunk mode and tag packets in VLAN 2. We have ports 17 and 18 on both switches connected to each other. One will enter in to forwarding mode and the other automatically gets disabled and reserved for failover usage.
Besides the two switches, there is no layer 3 router connected. Only devices that have static IP addresses assigned to them. (They are Dante devices in case you are curious: http://www.audinate.com/)
It is ideal to have IGMP snooping because it can cut down on a lot of unnecessary duplicate traffic. However it does not seem to work correctly. I have enabled IGMP V3 snooping on both switches, as well as IGMP querying. (I have also tried it with the querying enabled on only one switch.) Internally the IGMP snooping seems to work and ports get subscribed to multicast groups. But the trunk ports do not get subscribed. So multicast group members on one switch do not see the members from the corresponding group connected on the other switch which results in no multicast traffic traversing the trunk. Listing the multicast group members in the web-ui, there are never any router-port members. I would think that the switch that ends up designated as a leaf node would have a trunk port designated as a multicast router-port.
If I turn off IGMP snooping, the multicast packets flood all ports between the two switches, but I would rather not do it that way. Is the problem with IGMP that I'm not doing something right, that is won't work without a layer-3 router, or perhaps a bug? Do I need to somehow set up a route for the IGMP multicast subscription address so that subscription data is pushed over the trunk ports?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-04-2014 05:25 PM
06-04-2014 05:25 PM
Re: IGMP Snooping failure with multiple swtiches
Figured it out. I needed to add a VLAN interface for each VLAN and register them as the query source so that there is a routable address to send query responses to.
Did a lot of reading today. Set switches in the same region and did some reading about MSTP instances, mapping VLANs to them, and binding the instnaces to specific ports in order to provide dedicated VLAN trunks. Working much better now.