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>

Reminder

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

upgrade

Multicast Source of IPTV Topology does not Enable Multicast Protocol and Parts of Channels are not Reachable

Publication Date:  2012-07-27 Views:  47 Downloads:  0
Issue Description
RPT on Xuefu C4506 is switched to STP, the port at downstream of forwarding table of multicast route on Hexing NE80E is reduced. Parts of multicast service cannot be accessed.  The topology can be referred to the attachment.
Alarm Information
Null
Handling Process
1. Check configuration, traffic and multicast forwarding table. They are normal.
2. Reset the problem when RTP is switched over STP:
Hexing NE80E
RPT 
dis multicast forwarding-table 224.11.1.1
Multicast Forwarding Table
Total 11 entries
00001. (221.212.252.174, 224.11.1.1), MID: 1030, Flags: 0x0:0
     Uptime: 3d:09h
     Incoming interface: GigabitEthernet2/0/0
     List of 17 outgoing interfaces:
       1: GigabitEthernet10/0/0.10-----(switchover stp and disappear)
       2: GigabitEthernet10/0/2.10
       3: GigabitEthernet11/0/6.10
       4: GigabitEthernet10/0/9.10
       5: GigabitEthernet11/0/3.10
       6: GigabitEthernet11/0/7.10
       7: GigabitEthernet11/0/0.10
       8: GigabitEthernet10/0/5.10
       9: GigabitEthernet11/0/2.10
       10: GigabitEthernet11/0/8.10
       11: GigabitEthernet10/0/7.10
       12: GigabitEthernet10/0/3.10
       13: GigabitEthernet10/0/6.10
       14: GigabitEthernet11/0/1.10
       15: GigabitEthernet10/0/8.10
       16: GigabitEthernet10/0/4.10       
       17: GigabitEthernet10/0/1.10
     Matched 58355134 packets(7469457152 bytes), Wrong If 0 packets
     Forwarded 0 packets(0 bytes)
 RPT is switched over STP.
      dis multicast forwarding-table 224.11.1.1
Multicast Forwarding Table
Total 11 entries
00001. (221.212.252.174, 224.11.1.1), MID: 1030, Flags: 0x0:0
     Uptime: 3d:09h
     Incoming interface: GigabitEthernet2/0/0
     List of 17 outgoing interfaces:
       1: GigabitEthernet10/0/1.10
       2: GigabitEthernet10/0/2.10
       3: GigabitEthernet11/0/6.10
       4: GigabitEthernet10/0/9.10
       5: GigabitEthernet11/0/3.10
       6: GigabitEthernet11/0/7.10
       7: GigabitEthernet11/0/0.10
       8: GigabitEthernet10/0/5.10
       9: GigabitEthernet11/0/2.10
       10: GigabitEthernet11/0/8.10
       11: GigabitEthernet10/0/7.10
       12: GigabitEthernet10/0/3.10
       13: GigabitEthernet10/0/6.10
       14: GigabitEthernet11/0/1.10
       15: GigabitEthernet10/0/8.10
       16: GigabitEthernet10/0/4.10       
     Matched 58386531 packets(7469497521 bytes), Wrong If 0 packets
     Forwarded 0 packets(0 bytes)
GigabitEthernet10/0/0.10 connects Xuefu SE800 device.
From the whole network, Hexing NE80E has two equal-cost routes that connect Hexing and Shangzhi NE80E. Before Changjiang NE80E is RP, but there is only one next-hop from Hexing NE80E to Changjiang NE80E. There is complete <*, G>, <S and G> entry, but Shangzhi NE80E has no related multicast route. RP offsets to C6509B. Join information sent on SE800 is first used by the device itselt and then it is sent to Shangzhi NE80E.
C. Locate which side the multicast traffic is prune through deb information.
Shangzhi NE80E enables deb information
*6.575255524 NE80E-A-ShangZhi PIM/8/JP:Public:PIM ver 2 JP  sending 221.212.1.38 -> 224.0.0.13 on GigabitEthernet2/0/0  (P011934)
Shangzhi NE80E receives request join information sent by Xuefu SE800. After <S and G> are established, they are sent to Zhongshan NE80E.GigabitEthernet2/0/0 is interconnected interface of Zhongshan NE80E.
Open deb on Zhongshan NE80E:
*6.574204484 NE80E-A-ZhongShan PIM/8/JP:Public:PIM ver 2 JP  sending 221.212.1.69 -> 224.0.0.13 on GigabitEthernet6/0/0  (P011934)
Zhongshan sends received join packet to GigabitEthernet6/0/0 C6509. Within  210 seconds there is no multicast traffic. The multicast traffic is prune. For the link of SE800 with load balance, after the closest rotuer is switched over STP, parts of multicast data are sent to Shangzhi NE80E. It is sent to C6509 through Zhongshan NE80E. It does not receive multicast traffic at upstream, <S and G> maintenance on NE80E are timeout and prune. Check C6509 and it is found that PIM is not enabled on interface of C4506. Requiring the building of source tree at downstream cannot be sent to actual multicast source. 210 seconds later <S and G> on Zhongshan NE80E are prune. Configure PIM source tree module on C6509 and C4506 and the service recovers.
Root Cause
1. Check configuration information.
2. Check whether there is error at NE80E and display multicast forwarding-table. 
3. Check multicast forwarding table after RTP is switched over STP.
4. Locate where multicast traffic is prune through deb information. 
Suggestions
Null

END