Got it

Q&A: how to solve the Delay in Failover response time for Multicast traffic

Latest reply: May 4, 2018 11:05:20 927 1 0 0 0

Issue Description

Streaming Media Server----------->XG0/0/5(S6720)XG0/0/23 &XG0/0/24-------->XG0/0/1&XG0/0/2(S5720)--------EDGE QUAM(Multicast feed receiver)

There are one of the ISP1 and ISP2 providing Data (Internet) and CATV services . Recently we had procured Huawei switches for us to carry and deliver both Data and Multicast services at various part. While doing implementation we had observed that if primary link goes down it took 30 to 40-Seconds for fail-over for Multicast stream to recover, due to this videos stream stops for 40-Seconds and surprisingly for data (Unicast) there is no delay observed with only single packet loss. Secondly if primary link get restored it also takes same time.<?xml:namespace prefix = "o" />

                                                Alarm InformationNone
                                                Handling Process1. The primary path and secondary path are independent, did not use eth-trunk interface binding;
2. Vlan igmp snooping is enabled on switches, and multicast traffic flows through the active path. When the primary path is down, the secondary path port will become a member port and the user rejoins the multicast group.
3. The topology of the Layer 2 network changes on the network, the forwarding path of multicast packets changes, and the multicast query regenerates. The upstream querier sends Query messages within a certain interval (the default interval is 60 seconds). After the Layer 2 network convergence is complete, the downstream device does not receive the Query packet immediately. Therefore, the multicast forwarding path cannot be quickly switched. The multicast switching time tested by the customer may be 30 to 40 seconds.
4. This scenario can be solved by configuring the fast forwarding function of the multicast forwarding path when the STP topology changes. When the STP topology changes, this function can rapidly add the interface in the forwarding state on the device to the router port, thus guiding the multicast data flow to quickly switch to the new forwarding path.
                                                Root CauseThe network configuration or design of multicast is unreasonable
1. The first way:
Configuring  the following command on S6720:
igmp-snooping fast-switch enable
2. The second way:
Currently, it is recommended to implement fast switchover of multicast traffic by binding eth-trunk.

                                                SuggestionsLink protection can be better implemented by configuring the eth-trunk link

This post was last edited by Barret at 2018-09-12 01:15.
  • x
  • convention:

Created May 4, 2018 11:05:20

View more
  • x
  • convention:


You need to log in to comment to the post Login | Register

Notice: To protect the legitimate rights and interests of you, the community, and third parties, do not release content that may bring legal risks to all parties, including but are not limited to the following:
  • Politically sensitive content
  • Content concerning pornography, gambling, and drug abuse
  • Content that may disclose or infringe upon others ' commercial secrets, intellectual properties, including trade marks, copyrights, and patents, and personal privacy
Do not share your account and password with others. All operations performed using your account will be regarded as your own actions and all consequences arising therefrom will be borne by you. For details, see " User Agreement."

My Followers

Login and enjoy all the member benefits


Are you sure to block this user?
Users on your blacklist cannot comment on your post,cannot mention you, cannot send you private messages.
Please bind your phone number to obtain invitation bonus.