No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search


To have a better experience, please upgrade your IE browser.


In the ring network, the switch hasn’t configured the Layer 2 multicast causes the IPTV service isn’t connectable.

Publication Date:  2019-07-24 Views:  113 Downloads:  0

Issue Description

The S93 have composed a RRPP ring, each S93 has connected the access device and provided the users with HIS, VoIP and IPTV service.
The live network version: S9300V100R002C00SPC200 + S9300V100R002SPH011
The networking diagram:

         P-------P----------IPTV central office
         |            |
|         RRPP      |
After completing to cut over, we find the user multicast traffic in the site E,F and G are not connectable, but the unicast service of the HIS and VoIP are both normal.
Firstly, confirm the multicast flow is down-streamed from the B, check the multicast entry in the B’s S93, there are 152 multicast entries, the upstream interface is VLANIF51, and the downstream interface is VLANIF50.
dis mu f
Multicast Forwarding Table of VPN-Instance: public net
Total 152 entries, 152 matched

00001. (,
MID: 35, Flags: 0x2:0
Uptime: 13:06:49, Timeout in: 00:00:00
Incoming interface: Vlanif51
List of 3 outgoing interfaces:
1: Vlanif50
2: Vlanif101
3: Vlanif100
Matched 448 packets(29568 bytes), Wrong If 0 packets
Forwarded 448 packets(29568 bytes)

Login the D device and check the multicast entry, the downstream user is VLANIF660, but it’s the RRPP ring, and the remaining port of the S9300 interconnecting ports are all in the VLANIF 50, the multicast entries have reduced sharply in the S93 of the G site, and there is remained the IGMP GROUP entry the user on-demanded; there doesn’t have more than 150 Multicast Forwarding Table in the S93 as the B site. And login the devices which have problem one by one, we find they all just have the IGMP GROPU entry the user on-demanded, but don’t have the multicast forwarding table.

Alarm Information


Handling Process

Currently, the S9300 in the network can all enable the Layer 2 multicast IGMP Snooping, and the Layer 2 multicast IGMP Snooping is also enable in the VLAN 50 of the RRPP ring.
The configuration is as followed:
[S9300]igmp-snooping enable
[S9300]vlan 50
[S9300]igmp-snooping enable

Take the S93 device in the site D as an example, after the Layer 2 multicast is enable, there will produce two router ports, then the Layer 3 multicast will forward the multicast flow of the VLAN 50 to other S9300 devices through the Layer 2 multicast output interface.
[WCC-S9300-PE-vlan50]dis igmp-snooping router-port vlan 50
Port Name UpTime Expires Flags
VLAN 50, 2 router-port(s)
GE2/0/0 00:00:50 00:01:43 DYNAMIC
GE1/0/0 00:00:31 00:01:44 DYNAMIC
[WCC-S9300-PE-vlan50]dis mu f s
Multicast Forwarding Table of VPN-Instance: public net
Total 144 entries

0 entries are registering
0 entries have register IIF
136 entries don't have OIF
0 entries are in delete state
0 entries are needed to sync to IO board
144 entries are calculated in statistics
Max 128 OIFs can be supported in each entry
Max 4096 entries can be supported in the table

After changing the configuration, there are full Layer 3 multicast entry in each S9300, and we have confirmed the devices which had problem now have restored to be normal.

Root Cause

Check the configuration of the S93, all the S93 have just configured the Layer 3 multicast and not configure any IGMP Snooping Layer 2 multicast, because all the upstream ports of the S9300s are in the VLAN 50, starting from the S93 device, the multicast flow will forward from internal Layer 2 in the VLAN 50 to the other S9300 device.
The Layer 3 multicast needs to be forwarded via the Layer 3 route, and currently the S9300 Layer 3 multicast just supports the VLANIF interface, while it needs to implement the Layer 3 multicast forwarding cross the VLAN, firstly it needs to hint the multicast forwarding entry, and find out the other Layer 3 output interface VLANIF, then forward it, and it can’t broadcast in the input VLANIF, which can avoid the flow flooding in the whole network segment. In the condition that there just runs the Layer 3 multicast in the RRPP ring, in the current configuration of the live network, we can’t forward the multicast flow.
This scene can simplify as a Layer 3 multicast forwarding in the input VLAN instance: it needs to enable the Layer 2 multicast in the ring VLAN 50, and produces the Layer 2 router port depending on the PIM Hello packet, the output interface learnt by the Layer 2 multicast will report to the Layer 3 multicast, then the multicast still can’t broadcast in the input VLAN 50, it will accurately forward to the output interface of the Layer 2 multicast in the input VLAN 50, and forward the Layer 3 multicast flow to the other S9300 devices in the upstream, and then the S9300 will replicate and distribute them to the downstream users.


While in the switches group RRPP ring network, make sure to implement the Layer 2 multicast function, or it may causes the multicast flow can’t be connectable.