09-12-2024 12:41 AM
Hi Guys,
I have in my network two IPTV headend streaming server which are both will stream same multicast IPs :
The two streaming IPTV headend I am planning to make them work as master and slave, if one of them down then IPTV server will handle the other multicast IP which is available in network.
Headend Streamer-1 (IP interface 192.168.0.1 connected with Core 6509e in location A) >>>>> multicast IPs 224.1.1.1 - 100:50000
Headend Streamer-2 (IP interface 192.168.0.2 connected with Core 6509e in location B) >>>>> multicast IPs 224.1.1.1 - 100:50000
I am thinking to use IP SLA trackinglike this:
# Create IP SLA to ping Streamer-1
Switch(config)# ip sla 1
Switch(config-ip-sla)# icmp-echo 192.168.1.2
Switch(config-ip-sla)# frequency 5
Switch(config-ip-sla)# exit
# Start the IP SLA
Switch(config)# ip sla schedule 1 life forever start-time now
# Primary route to Streamer-1
Switch(config)# ip route 224.1.1.1 255.255.255.0 192.168.1.2 track 1
# Backup route to Streamer-2
Switch(config)# ip route 224.1.1.1 255.255.255.0 192.168.2.2
Does this way is correct?
Solved! Go to Solution.
09-12-2024 12:59 AM
Hello @mohammadSaeed01 ,
if using PIM SSM you can discriminate between the two sources.
the fact that primary server answers to ICMP echo requests sent to its IP address does not mean that the server is actually streaming.
The multicast streaming service can be stopped and the server is still able to answer to ping.
The best solution for this is to use PIM SSM and have receivers join to secondary server when primary server stop to provide the stream.
It can be solved at application level using PIM SSM
Hope to help
Giuseppe
09-12-2024 12:59 AM
Hello @mohammadSaeed01 ,
if using PIM SSM you can discriminate between the two sources.
the fact that primary server answers to ICMP echo requests sent to its IP address does not mean that the server is actually streaming.
The multicast streaming service can be stopped and the server is still able to answer to ping.
The best solution for this is to use PIM SSM and have receivers join to secondary server when primary server stop to provide the stream.
It can be solved at application level using PIM SSM
Hope to help
Giuseppe
09-12-2024 03:31 AM - edited 09-12-2024 03:32 AM
Hello @mohammadSaeed01 ,
just a note : if you want to try to use PIM SSM you need to enable igmp version 3 on interfaces of network devices and what is more important you need to check that the receivers support IGMPv3.
Hope to help
Giuseppe
09-12-2024 07:03 AM
Thanks for solution but will work if my two headend IPTV streamer in different location? because one IPTV headend streamer will be on site-1 and other one will be located on site-2 but there is a communication between them.
Will PIM SSM work in this scenario? or should be connected physically at same core switch?
Thanks
09-12-2024 08:07 AM
Hello @mohammadSaeed01 ,
it can work if all the links including alternative higher cost paths have ip pim sparse mode enabled and all devices agree on what mutlicast groups are to be treated as PIM SSM.
Setting of IGMP version 3 is needed only on user facing VLAN L3 SVIs.
With IGMPv3 the receiver sends a join that tells the group G and the source S it wants to listen to ( or alternatively it can say the Group G and a source it doesn't want to listen to).
Because the source is known from the begining the source based tree can be built without going first towards an RP and this is another advantage of PIM SSM it does not need RP = Rendevous point and there is no need to distribute RPs to Groups mappings.
You have to verify that the source is sending multicast packets with a TTL > 1 typical values can be 16 or 32 so that the stream can reach receivers in remote locations.
Hope to help
Giuseppe
09-12-2024 10:06 AM
09-12-2024 02:40 PM - edited 09-12-2024 09:37 PM
Hello @mohammadSaeed01
you can use the following article
https://mrncciew.com/2021/04/12/source-specific-multicast-ssm/
Hope to help
Giuseppe
09-12-2024 03:54 AM
Hello
due to multiple next-hops for your MC , It may be applicable to apply multicast mutlipath, this could offer source mc source load splitting , based on single source <> single and/or multiple groups
example mc hashing
ip multicast multipath s-g-hash basic <> ( source/group) default
ip multicast multipath s-g-hash next-hop-based <> (source/group & nexthop )
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide