How do I constrain multicast traffic to specific ports on GS716Tv3?

[cwebster]

I can't find specific instructions to constrain multicast traffic on the GS715Tv3 smart switch.

I need to force all multicast traffic to travel over a specific set of interfaces, or at least to stay within a given vLAN on the switch on which it originated. All desired muticast servers and listeners will be on these interfaces within their separate vLAN.

We have multiple GS715Tv3 switches configured identically but multicast traffic must not pass between switches.

Topology:

Eight GS716Tv3 smart switches, each configured with three identical vLANS.

No traffic should pass between these vLANs on the switch or pass between switches

In other words, even though all 8 switches each have a vLAN named "IOSubsystem", I do not want them considered the same vLAN.

.

vLAN 4 is for the main Linux host computers

vLAN 5 is for the audio subsystem

vLAN 6 is for the I/O subsystem

Each switch's vLAN 4 has two active ports, one going to the outside interface of a main Linux host, and the other to a central 9th GS716Tv3 switch where a software development system is also connected.

Each switch's vLAN 5 connects to audio subsystem components (not shown).

Each switch's vLAN 6 has two active ports, one going to the inside interface of a main Linux host, and the other to the I/O subsystem.

           ->[vLAN4|g10]----------------------->[Switch #9]---+
           ->[vLAN4|g9]->[Linux Host #1|eth0]                 |
[Switch #1]->[vLAN6|g1]->[Linux Host #1|eth1]                 |
           ->[vLAN6|g2]->[I/O Subsystem #1]                   |
                                                              |
           ->[vLAN4|g10]----------------------->[Switch #9]---+----->[Software Dev Host]
           ->[vLAN4|g9]->[Linux Host #2|eth0]                 |
[Switch #2]->[vLAN6|g1]->[Linux Host #2|eth1]                 |
           ->[vLAN6|g2]->[I/O Subsystem #2]                   |
...                                                           ~
                                                              |
           ->[vLAN4|g10]----------------------->[Switch #9]---+
           ->[vLAN4|g9]->[Linux Host #8|eth0]
[Switch #8]->[vLAN6|g1]->[Linux Host #8|eth1]
           ->[vLAN6|g2]->[I/O Subsystem #8]

We are getting unwanted muticast traffic between each of these systems, causing corruption of our data stream. We need to restrict multicast traffic on vLAN6 of each switch to stay on vLAN6 of that specific switch.

Thank you for any help.

[Napsterbater · Accepted solution]

To switch the the Mangement VLAN to 4.

Make sure you have 2 ports on the switch, one in VLAN1 one in VLAN4.

Set the system you are using to a static IP in the range of the switch and confirm access to the web config then change the "Management VLAN ID" to 4 and Apply. then switch the system you are using to the port or any port in VLAN 4 then you should have access, if not, wait about 60-90sec and try again becuase you may have STP on and it will block anything on the port for a bit unless its set to "Fast Link" Enabled.

Then under "IP Configuration" set the switches IP address to somthing in in IP range of VLAN4.

For Simplisicty sake, Untagged ports should only ever be in 1 VLAN at a time.

And instead of using the point and click, goto "Port PVID Configuration" and just set the VLANs there.

Set PVID and VLAN member the same for a port, based on what VLAN it needs to be in

And to confirm, do you have a cable going from switch to switch for each VLAN? You could cut down on cables and ports if you trunk/tag the ports to the next switch. then all 3 VLAN would only need 1 cable between each pair of switches, saving you atleast 4 ports on each switch.

Just an example from my GS724T (ignore ports g8 and g19-20, thier Current PVID is becuase of somthing else you are not doing, LACP and Span/Monitoring):

All ports are setup for a single VLAN, my "Main LAN" is VLAN12, which the mangement VLAN is set for aswell, ports g23-24 are VLAN Trunks, they are set to tagg VLAN12 and 14 when that traffic goes out of those ports, then the switch on the other side reads the tagg and acts acordingly, this way I dont need 2 cables/ports for each of those.

[DaneA]

Hi cwebster,

Have you already came across with these articles below?  It might help you with your concern: 

http://kb.netgear.com/app/answers/detail/a_id/21776/~/what-is-internet-group-management-protocol-(ig...

http://kb.netgear.com/app/answers/detail/a_id/21778/~/how-do-i-enable-internet-group-management-prot...

Hope it helps.  Welcome to the community! 

Regards,

DaneA

NETGEAR Community Team

[cwebster]

Thank you Dane. I think that's the part I was missing, about having to have a router to manage the multicast group membership. I'll try that when the systems are available again today.

First, however, I'm going to try renaming the vLANs so they don't all match. I'm not quite sure whether the multicast traffic is being forwarded between switches because of the identically named vLANs or because the switch automatically forwards all multicast traffic to all vLANs on the local switch. The one vLAN that's connected to all switches would then distribute the traffic to all. Can you clarify this behavior?

Best Regards,

Cal Webster

[DaneA]

Hi @cwebster,

---

@cwebster wrote:

I'm not quite sure whether the multicast traffic is being forwarded between switches because of the identically named vLANs or because the switch automatically forwards all multicast traffic to all vLANs on the local switch. The one vLAN that's connected to all switches would then distribute the traffic to all. Can you clarify this behavior? 

---

With regard to this, if multicast traffic is being forwarded to all VLANs then it is not multicast at all.  That would be broadcast.

Kindly refer to the first link I have provided to you. 

Regards,

DaneA

NETGEAR Community Team

[cwebster]

I don't know if it's being forwarded to all vLANS Dane. All I know is that there are multicast packets (multicast addr 225.0.0.250)  from [IOSubsystem1] on one switch being forwarded to [IOSubsystem2] on a separate switch. The only thing physically connecting these two switches is cable from each one's [SimvLAN] going to the [SimvLAN] on a separate development lab switch. See illustration below. When I pull the plug on the development network connection, the data stream corruption ceases - packets are no longer forwarded.

[Switch 1|I/OvLAN1]->[LinuxHost1]

[Switch 1|I/OvLAN1]->[IOSubsystem1]

[Switch1|SimvLAN]

             +

             |

             +

[Switch9|SimvLAN]----------------->[DevHost]

             +

             |

             +

[Switch2|SimvLAN]

[Switch 2|I/OvLAN2]->[LinuxHost2]

[Switch 2|I/OvLAN2]->[IOSubsystem2]

I have configured an IGMP Snooping Querier on one of the GS716Tv3 switches [Switch1]. I used IP address 192.168.55.100 for the querier address, an available address from the network on the affected vLAN.

In "Querier vLAN Configuration" I added vLAN 6 [IOvLAN1], the affected vLAN.

Then in "IGMP Snooping vLAN Configuration" I added vLAN 6 [IOvLAN1].

I'm not sure where to go from here, though. It looks like everything I've done up to now is geared toward identifying and tracking multicast traffic. How do I actually tell the switch to keep its multicast traffic ONLY on the 3 ports that comprise vLAN 6 [IOvLAN1]?

Thank you for your help!

Cal Webster

[cwebster]

I've resolved the data stream curruption issues but I still need to know how to configure this switch to control multicast traffic.

To resolve the data stream corruption I reconfigured the players to use the reserved, local subnet block of multicast addresses (224.0.0.0 to 224.0.0.255). This was still not sufficient, though. I had to re-assign a separate multicast address to each pair of players on each switch's [IOvLAN] in order to prevent cross-talk. Even though these switches are not stacked and the vLANS are not tagged, they are passing local traffic between each other for what should be isolated vLANs. IOvLAN on switch 1 should be completely isolated from IOvLAN on switch 2 unless I plug something in there to route traffic.

I still can find nothing to describe how to actually control the multicast traffic that I've configured to snoop on the switch. I'm not even sure I've configured snooping correctly because I don't see anythin listed in the "IGMP Snooping Table". Isn't there a HowTo somewhere? These are things I would expect to find in the Software Admin manual but that's just a series of individual steps to perform sub-tasks.

Any useful tips from those who have done this before would be appreciated.

Regards,

Cal Webster

[DaneA]

Hi cwebster,

As long as IGMP Snooping is configured correctly, there should be no issues with the multicast traffic crossing VLANs. 

Let me also share this link I have found online.  Hope this will help as reference.

Regards,

DaneA

NETGEAR Community Team

[cwebster]

Thank you for that link Dane. The instructions were much more explanatory than those in the admin guide. I went through those same steps before but used a different querier address. I changed the querier address to that of the switch and configured vLAN 6 since that's the vLAN from which the multicast traffic originates and the one in which I wish to constrain the traffic.

I don't think it's working, though, because there are still no entries at all in IGMP Snooping Table. I expected to see the two players on vLAN 6. Shouldn't there be some MAC addresses in this list?

Should I have configured vLAN 1 instead of 6, even though 6 is the one I want to keep the traffic on?

Regards,

Cal Webster

[DaneA]

Hi cwebster,

I think one way to check if multicast traffic is being constraint within VLAN 6 is to configure port mirroring and monitor it using Wireshark.  Check this article about port mirroring.  

In VLAN 6, you will need to set a source port/s and a destination port for port mirroring.  The source port/s is/are the VLAN 6 port/s that you want to check if multicast is being constraint and the destination port is a one port in VLAN 6 where you will connect a PC/laptop that has Wireshark installed to monitor it.  Here is the article as reference guide on how to configure port mirroring on the GS716Tv3.  

Here is the link where to download Wireshark.  Check this link I found online as reference how to analyze IPv4 multicast traffic.  Also,  you may search videos online (such as YouTube, etc.) or how-to documents about Wireshark.

Regards,

DaneA

NETGEAR Community Team

[Napsterbater]

Multicast should'nt be leaving the VLAN not matter what, IGMP or not, just like Broadcast, unless you have a) A Multicast router, or b) You have a config issue with your VLANS. IGMP only keeps multicast from going to ports/devices that have not requested the multicast traffic.

How are the VLANS configured on the ports betweeen Switch1 and Switch9, then how are they configured between Switch2 and Switch 9?

Are you Tagging the Packets/are they setup for VLAN Trunking?

or

Are they set as Access Ports/untagged and just assgined to a single VLAN.

Also VLAN Names do not matter they are for your info only, VLAN Numbers will though.

I think you have made one big single Layer 2 "broadcast" domain.

[cwebster]

---

Thank you for taking time to respond Napsterbater.

I have discovered the fundamental issue causing this problem and solved it - explanation below. First, I'll address your questions.

[quote]

Multicast should'nt be leaving the VLAN not matter what, IGMP or not, just like Broadcast, unless you have a) A Multicast router, or b) You have a config issue with your VLANS. IGMP only keeps multicast from going to ports/devices that have not requested the multicast traffic.

[/quote]

Exactly my point. I expected that when I configured these VLANs they would be isolated unless I plugged in a router or otherwise configured the switch to forward packets elsewhere.

[quote]

How are the VLANS configured on the ports betweeen Switch1 and Switch9, then how are they configured between Switch2 and Switch 9?

[/quote]

Switches 1 through 8 are each connected via a cable plugged into a port in each's VLAN4 and premise wiring back to Switch 9 for software development.

[quote]

Are you Tagging the Packets/are they setup for VLAN Trunking?

or

Are they set as Access Ports/untagged and just assgined to a single VLAN.

[/quote]

There is no tagging or VLAN trunking. All VLAN ports are simple, untagged access ports.

[quote]

Also VLAN Names do not matter they are for your info only, VLAN Numbers will though.

[/quote]

This was always my understanding of VLAN ports too, but when things were not behaving as I expected I began to wonder if Netgear was performing some kind of voodoo behind this scenes.

[quote]

I think you have made one big single Layer 2 "broadcast" domain.

[/quote]

You are almost exactly correct. The problem was that, even though I configured these ports into separate VLANs, the switch left the ports also members of the default VLAN 1. The Software Administration Manual does not mention that VLAN ports must be manually removed from VLAN 1. Nor does it specify that VLAN ports must be configured with a PVID before they will work as expected.

To resolve my issues:

1. Configured the member ports with a PVID:

Switching->VLAN->Advanced->Port PVID Configuration

Selected ports in VLAN 6 by clicking the check-box

Typed "6" in "Configured PVID" field

Selected "Enable" in the "Configured Ingress Filtering" field

Clicked [Apply] button

Did the same for VLANs 4 and 5

2. Removed ports in my new VLANs from membership in VLAN 1

Switching->VLAN->Advanced->VLAN Membership

VLAN 1 is selected by default

Clicked to change port assignments from "Untagged" (U) to unselected (blank) for ports configured in VLANs 5 and 6.

Clicked [Apply] button

Left VLAN 4 alone (see below)

Unresolved Issues:

[Background]

Each of Switches 1 through 8 are part of a series of aircraft simulators. Switch 9 is on an engineering network. VLAN 5 is used for audio subsystems and VLAN 6 is used for other I/O subsystems (sensors, switches, relays, pumps, etc.) on each simulator. VLAN 4 is the VLAN that connects all these simulators together for research and software development on Switch 9.

1. I have as yet been unable to remove VLAN 4 ports from VLAN 1 without loosing management of the switches. Switch management is done from the engineering network on VLAN 4. I've tried changing the "Management VLAN ID" to 4 then removing them from VLAN 1 but I loose access and have to reset to factory defaults and start over.

2. I still don't see any evidence on the switch that IGMP Snooping is actually working. As I indicated in an earlier post, there is nothing in the IGMP Snooping Table after configuring IGMP Snooping and the IGMP Snooping Querier. There have been multiple sessions where multicast traffic has occurred since I first configured it so I'd expect something to show up here.

I'm fairly certain that it has had an impact on the flow of multicast traffic because, prior to discovering the solution above, configuring IGMP Snooping did seem to resolve half of the cross-talk issues.

I'll be capturing traffic on VLAN 6 (I/O Subsystems) of one of these simulators to analyze the traffic over the next few weeks in an effort to understand how this switch feature actually affects the flow of multicast, broadcast, and unicast packets.

Thanks again for responding.

Best Regards,

Cal Webster

[Napsterbater · Accepted solution]

To switch the the Mangement VLAN to 4.

Make sure you have 2 ports on the switch, one in VLAN1 one in VLAN4.

Set the system you are using to a static IP in the range of the switch and confirm access to the web config then change the "Management VLAN ID" to 4 and Apply. then switch the system you are using to the port or any port in VLAN 4 then you should have access, if not, wait about 60-90sec and try again becuase you may have STP on and it will block anything on the port for a bit unless its set to "Fast Link" Enabled.

Then under "IP Configuration" set the switches IP address to somthing in in IP range of VLAN4.

For Simplisicty sake, Untagged ports should only ever be in 1 VLAN at a time.

And instead of using the point and click, goto "Port PVID Configuration" and just set the VLANs there.

Set PVID and VLAN member the same for a port, based on what VLAN it needs to be in

And to confirm, do you have a cable going from switch to switch for each VLAN? You could cut down on cables and ports if you trunk/tag the ports to the next switch. then all 3 VLAN would only need 1 cable between each pair of switches, saving you atleast 4 ports on each switch.

Just an example from my GS724T (ignore ports g8 and g19-20, thier Current PVID is becuase of somthing else you are not doing, LACP and Span/Monitoring):

All ports are setup for a single VLAN, my "Main LAN" is VLAN12, which the mangement VLAN is set for aswell, ports g23-24 are VLAN Trunks, they are set to tagg VLAN12 and 14 when that traffic goes out of those ports, then the switch on the other side reads the tagg and acts acordingly, this way I dont need 2 cables/ports for each of those.

[cwebster]

Thank you again Napsterbater!

There were several "spare" ports already in VLAN 1 so on the "Port PVID Configuration" page I changed "Configured PVID" and "VLAN Member" to 4 (and only 4) and set "Configured Ingress Filtering" to Enable on one of them then clicked [Apply]. I was plugged into a VLAN 1 port at the time. Then I Went to System->IP Configuration, changed "Management VLAN ID" to 4, and clicked [Apply]. Of course I lost the connection until I plugged into the VLAN 4 only port. Then I went back to "Switching->VLAN->Advanced->Port PVID Configuration" and changed the original VLAN 4 ports, which were also VLAN 1 members, setting "Configured PVID" and "VLAN Member" to 4 (and only 4) and set "Configured Ingress Filtering" to Enable. Now everything works as expected.

Before I was hopping between the VLAN Membership and Port PVID Configuration pages to try to accomplish the same thing. I didn't realize I could do everything on the Port PVID Configuration page.

[quote]

And to confirm, do you have a cable going from switch to switch for each VLAN? You could cut down on cables and ports if you trunk/tag the ports to the next switch. then all 3 VLAN would only need 1 cable between each pair of switches, saving you atleast 4 ports on each switch.

[/quote]

The only VLAN that is connected between simulators is VLAN 4. This VLAN is used for access to the host computers for distributing software updates and engineering. VLAN 5 and 6 are completely isolated within each simulator. The Audio and IO from one simulator should never communicate with the Audio or IO of the other. You might imagine the kind of confusion and chaos this could (did) cause.

[Sim 1 Host]----[sw1-vlan4]----|   |
[Sim 1 Audio]---[sw1-vlan5]    | s |
[Sim 1 IO]------[sw1-vlan6]    | w |
[Sim 1 Host]----[sw1-vlan6]    | i |
...                            | t |---[Devel Svr]
[Sim 8 Host]----[Sw8-vlan4]----| c |
[Sim 8 Audio]---[sw8-vlan5]    | h |
[Sim 8 IO]------[sw8-vlan6]    |   |
[Sim 8 Host]----[sw8-vlan6]    | 9 |

Interesting way you're hauling traffic between switches. There is a similar setup here with non-Netgear switches. Traffic for the main VLANs are tagged and forwarded over a pair of GBIC ports over fiber to another wing of the building.

Thank you again for the help.

Cal Webster