cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1412
Views
0
Helpful
10
Replies

Adding another multicast range

haroldsemqa
Level 1
Level 1

Hey guys!

I was recently transferred to a new hotel property which has a 3750 core switch for IPTV via multicast and some other services as well. A few days ago our network operator installed another 3750 switch that serves IPTV multicast as well and the management wants to integrate it to the existing network. I am still quite new to multicast routing so any input and feedback will be appreciated.

A few points to consider:

1. The core switch has a different multicast range than the new switch

2. Only one available interface on the core switch (int 12)

I have attached the current running config of the core switch but we cannot touch the one from the network operator

Thanks!

Harold

10 Replies 10

chrihussey
VIP Alumni
VIP Alumni

The multicast configuration on your switch has no access list tied to the RP so you are not restricting any multicast groups. The fact that the other core is using a different range is probably a good thing in that regard.

The question is, how will the connection to the other switch be accomplished?

If strictly a layer 2 connection and you assume the routing and IPs, then adding another multicast group will be rather simple.

If it will be a routed layer 3 connection, you will need to configure the RP on the other switch and add "pim sparse-mode" to the appropriate interfaces.

I was thinking that I will stay with layer 2 since the network operator limits our "interaction" with the leased switch they've installed. My colleague who was present when they installed and tested the multicast with them said that we can either use port 1 or the uplink port, the multicast range is in the 239.x.x.x but they didn't assign any local IP on the ports which left me dumbfounded...

If the leased switch was a single flat network, then an IP may not have been necessary in their environment. I assume you would create a new VLAN and interface on your switch to accommodate this network.

The question then becomes was this a stand alone switch or is there more of a network here that warrants consideration.

I can't actually tell for now if the existing switch is stand-alone since no network diagram has been handed over yet, but from my visual inspection i saw several video streamers and a few ASR routers and seems all are connected to the 3750 (the cabling is a total mess and it will take a while to organize it)

Hello

Can you confirm the exiting MC is working and this new switch will also require the use of MC?

If the MC source is on the same vlan as your clients then all is good, you will not require  PIM however this traffic needs to cross subnets and routed then you will require the assistance of PIM to forward that traffic to your hosts.

For L2 , Igmp is enabled by default which will help distribution the mc traffic to all ports on the broadcast network (vlan) - Igmp snooping (enable by default)  will help the switch control the multicast traffic on ports that don't require it

If pim is required then you need to enable MC routing globally and then on the specific interfaces needing it
You can use either dense / sparse mode.

Dense mode - will push out MC to every router/host port it has pim enabled on,even if they don't require this traffic and eventually being pruned off after a matter of time - which can consume unwarranted BW and processes

Sparse mode
- Unlike dense mode, Sparse will only send mc when it been requested to do so from a downstream router or from a host directly connected to the subnet its interfaces via igmp.

Its requires RP's to send and receive MC on the mc host behalf, so these specified RPs need to be routable on the network.
By default the RP's will send all MC traffic to all groups unless you specify specific groups for each RP,  So can you confirm if your current RP 10.1.1.254 will be doing this for both MC sources?

Lastly I can see in your CFG that interface 12 is currently a spanned (mirrored) port I guess for some monitoring.

res
Paul


 


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Yes MC is working on both the existing and the new switches and the current RP will handle both MC traffic.

I think port 12 was configured previously but for now it's free, so I can use it to connect the new switch

Hello

so basically all you need to default that interface 12 and re create it as a trunk attach this new switch which should also have trunk interface and you should be good to go!

res

paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Do I need to assign the native vlan to which the trunk will forward the traffic?

Hello

yes you will / as this is interface specific liase with your 3 party who administers the other switch as to what you wish this to be - it better to have an unused vlan than the default vlan 1 for this due to security issues 

Res

paul


Please rate and mark as an accepted solution if you have found any of the information provided useful.
This then could assist others on these forums to find a valuable answer and broadens the community’s global network.

Kind Regards
Paul

Will it have any issues if I use the same vlan as with the existing MC group?