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 Services Are Interrupted Due to Improper Processing of Packets With RP Information

Publication Date:  2012-07-27 Views:  73 Downloads:  0
Issue Description
 The networking is as follows:
Multicast source―Switch―C6509―S8512―NE20―PC
|
PC
Software version of the NE20: V200R005C02B383
The multicast source consists of 300 cameras; each camera uses a multicast group; 10 cameras are converged to a switch; the switches are converged to the C6509. The C6509, S8512, and NE20 run OSPF. The gateways of the PCs are configured on the S8512 and NE20. The PIM-SM protocol is deployed on the network, and dynamic RP preference is performed among the devices on the network. The BSR is the C6509.
The PC attached to the S8512 can normally display videos from the multicast source, whereas the PC attached to the NE20 can display only certain videos.
After the display pim neighbor command is run on the NE20, the output shows that a PIM neighbor relationship is successfully established between the NE20 and S8512. In addition, the output of the display pim rp-info command shows only three multicast groups and their RPs. If you run the same command on the S8512, you can view all the multicast groups and their RPs. 

 
Alarm Information
 Null 

 
Handling Process
 Because the C6509 is not a Huawei product and the customer does not agree to statically configure the RPs corresponding to all the multicast groups on the C6509, the problem can be solved only after the RPs are statically configured on the NE20.
As RPs vary with multicast groups, the only method is to specify a multicast group in an ACL and then apply the ACL in the PIM view to specify the corresponding RP address.
A static RP is configured as follows:
Take the multicast group 234.1.0.31/32 and the RP 10.165.1.1 as an example:
1. Create a basic ACL (note that basic ACLs rather than advanced ACLs are applicable to static RPs).
rule 0 permit source 234.1.0.31 0
rule 5 permit source 239.255.255.0 0.0.0.255 (Addresses in the 239 network segment are multicast group management addresses. A multicast client needs to use this multicast group to obtain the address of the desired multicast group. Therefore, this multicast group must be permitted in the ACL. You can run the display pim rp-info command on the NE20 to view information about this multicast group.)
quit
2. Enter the PIM view, and then configure a static RP and specify the corresponding ACL.
pim
static-rp 10.165.1.1 2001
quit
For the configurations of the NE20, see the attachment. 

 
Root Cause
 The BSR sends RP information corresponding to a multicast group to all the routers in the multicast domain. Because there are many multicast groups (and thus a lot of RPs) in this multicast domain, the BSR cannot send information about all RPs through one packet. Instead, the BSR sends information about all RPs through several packets.
As the designer of the NE20 did not take the situation of many multicast groups and corresponding RP information into consideration, the NE20 can handle only one packet carrying information about multicast groups and their RP addresses from the BSR.
In the case that the BSR sends several packets with information about multicast groups and their RP addresses, the NE20 deletes the existing RP information and keeps only the RP information carried in the last packet. In this example, the last packet sent by the BSR contains information about only three multicast groups and their RPs, and thus you can view information about these three multicast groups on the NE20. Information about multicast groups and RPs carried in the earlier packets are deleted. 

 
Suggestions
 In the case of many multicast groups and RPs, configuring static RPs brings huge workload and imposes difficulties on maintenance. Thus, it is recommended that a static RP be configured for the entire network to rectify the fault. 

 

END