Using IP SLA tracking between two streaming servers

[mohammadSaeed01]

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?

[Giuseppe Larosa · Accepted solution]

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

[Giuseppe Larosa]

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

[mohammadSaeed01]

Hi @Giuseppe Larosa 

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

[Giuseppe Larosa]

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

[mohammadSaeed01]

@Giuseppe Larosa 

Is there any live example or configuration guide can help me in that?

thanks

[Giuseppe Larosa]

Hello @mohammadSaeed01 

you can use the following article

https://mrncciew.com/2021/04/12/source-specific-multicast-ssm/

Hope to help

Giuseppe

[paul driver]

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 )