Vlans are your friend.
Yes - I agree... they can be when treated properly.
I say this - for general consumption rather than to inspire terror! Please be very careful when using IP multicast with VLANs- there is a "soft" default port mode that I have seen on Cisco and HP enterprise switches.
IP multicast can sometimes "escape" from a VLAN, as this is a "feature" used by services like IPTV.
This can really give you a bad day with some clocking schemes.
Solution:
On Cisco- say we want ports 1-4 to be VLAN 2 and ports 5-8 to be VLAN 3 (I am deliberately leaving out VLAN 1 for the moment- this will become clear)
My first task is to do
(please excuse innacuracies... this is off the "top of my head"
>enable
#config t
#interface range gi 0/1 - 0/8
config-if#switchport mode access
<-- the last step above is very important, you don't want the switch doing its default thing of choosing whether a port is a trunk or an access port ad-hoc... this is cool for an edge switch in a branch office... very uncool for a serious data network !-->
next we want to put some ports in a VLAN
#interface range gi 0/1 - 0/4
config-if# switchport access VLAN 2
Normally - most people stop here... on an IP unicast network, this is all you have to do...
However services like Dante clock - when there is a primary and secondary network sharing a switch need to be kept separate... we do this as so
config-if# switchport forbid VLAN 3
config-if# switchport forbid VLAN 1
This is assuming that there are only VLANs 1,2,and 3 in the switch
I am also assuming that the whole VLAN-DA process has been done to create the VLANs in the first place.
next up, we do the same for the secondary
config-if# interface range gi 0/5 - 0/8
config-if# switchport access VLAN 3
config-if# switchport forbid VLAN 2
config-if# switchport forbid VLAN 1
I will cross check this against a Cisco IOS device... but the point above is to show a principle, not a method of execution.
NB - once we have the access ports all nicely separated... we can still do a dot1q trunk and put the primary and secondary VLANs on the same physical port, after all we are sure that the IP multicast has been put in frames that have the dot1q header filled in correctly.
I only know this because I had to do it a few hundred times... took a while to work out... hopefully will save some of you time and stress.
As they say on a popular show here- stay safe and don't have nightmares