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

Reminder

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

upgrade

NE40E V800R010C10SPC500 Configuration Guide - IP Multicast 01

This is NE40E V800R010C10SPC500 Configuration Guide - IP Multicast
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
Licensing Requirements and Limitations for PIM

Licensing Requirements and Limitations for PIM

Licensing Requirements

This feature is a basic feature and is not under license control.

Restrictions and Guidelines

Restrictions

Guidelines

Impact

PIM FRR does not support low-rate multicast traffic or multicast traffic with constant changing rates (no data packets exist in the configured detection period, which is 20 ms by default).

PIM FRR supports source-and group address-based deployment. Do not deploy PIM FRR for low-rate multicast services. Adjust the default detection period to adapt to low-rate multicast services and reduce the switchover time.

In scenarios with low-rate multicast traffic or multicast traffic with constant changing rates, PIM FRR frequently performs switchovers mistakenly, resulting in packet loss.

A multicast inbound interface supports PIM FRR deployment only if the interface is a Layer 3 Ethernet main interface, Ethernet sub-interface, Layer 3 Eth-Trunk interface, or Eth-Trunk sub-interface. If both or either of the master and slave inbound interfaces do not support PIM FRR, PIM FRR does not take effect. In this case, traffic is forwarded in common multicast mode, and protection cannot be implemented.

None

PIM FRR does not take effect, traffic is forwarded in common multicast mode, and protection cannot be implemented. Traffic switchovers depend on protocol hard convergence, and rapid switchovers are not supported.

PIM FRR has the following limitations in ring networking scenarios:
  • Intermediate devices must be configured with PIM FRR.
  • Intermediate devices cannot be connected to non-~HUAWEI devices.

None

Protection cannot be implemented.

In IPv4 multicast VPN (Rosen) scenarios, deploy PIM FRR on both source-end and receive-end devices. Otherwise, protection cannot be implemented. If PIM FRR is deployed on the receive-end device but not on the source-end device, no public-network protection forwarding paths are available for receive-end VPN protocol packets, causing VPN protocol forwarding failures if the public-network forwarding path fails. VPN protocol packet forwarding can recover only after route convergence is complete on the public network.

Deploy PIM FRR on both source-end and receive-end devices.

In fault scenarios, VPN multicast protocol packets may be discarded due to the lack of protection, causing VPN route re-convergence. The packet loss duration depends on the protocol convergence duration.

In IPv4 multicast VPN (Rosen) scenarios, PIM FRR deployment requires the configuration of an integrated board (using the multicast-vpn slot slot-id command), preventing link faults from triggering service processing board migration and switchback time exceeding 50 ms.

Specify a board for integrated multicast VPN service processing.

Path-switchback-triggered packet loss exceed 50 ms.

In Rosen MVPN scenarios, if PIM FRR is deployed on the public network, low-speed traffic cannot be filtered out based on VPN (S, G) entries. In this case, you can configure a switching threshold to confine low-speed services to Share-Group and then use an ACL to filter out traffic in Share-Group. Deploying PIM FRR on VPNs cannot solve the co-routing problem of the public network.

Configure a switching threshold to confine low-speed services to Share-Group and then use an ACL to filter out traffic in Share-Group.

PIM FRR deployed on the public network cannot filter out the low-speed traffic on a VPN. PIM FRR deployed on a VPN cannot solve the co-routing problem of the public network.

In a multicast scenario with equal-cost links or primary and secondary links, PIM is enabled only for the active link in use, but not enabled on the other links. After a link switchover occurs due to a configuration, route, or link change, multicast services will be interrupted, because PIM is not enabled on the newly selected link.

If multicast services need to be transmitted along optimal routes of non-equal-cost links, PIM also needs to be enabled.

enable PIM in the views of the interfaces on which PIM is disabled.

After a switchover, PIM routes are uNonevailable, and multicast services are interrupted.

In a multicast scenario with equal-cost links or primary and secondary links, PIM is enabled only for the active link in use, but not enabled on the other links. After a link switchover occurs due to a configuration, route, or link change, multicast services will be interrupted, because PIM is not enabled on the newly selected link.

If multicast services need to be transmitted along optimal routes of non-equal-cost links, PIM also needs to be enabled.

enable PIM in the views of the interfaces on which PIM is disabled.

After a switchover, PIM routes are uNonevailable, and multicast services are interrupted.

Source cloning-based PIM FRR cannot protect multicast traffic whose rate is lower than 200 pps. You must configure an ACL to filter out such traffic.

Configure an ACL to filter out low-speed multicast traffic.

PIM FRR does not work for multicast traffic.

Source cloning-based PIM FRR supports only the LPUF-51-E/LPUI-51-E/LPUI-51-S/LPUI-51-CM/LPUF-120/LPUF-120-B/LPUF-120-E/LPUI-102-E/LPUI-120/LPUI-120-B/LPUI-120-L/LPUI-52-E/LPUI-120-E/LPUI-120-CM/LPUF-240/LPUF-240-B/LPUF-240-E/LPUI-240/LPUI-240-B/LPUI-240-CM/LPUI-240-L/LPUF-480/LPUF-480-B/LPUI-480/LPUI-480-B/LPUI-480-L/LPUF-480-E/LPUI-480-CM/LPUF-400-E boards.

NA

Only certain multicast groups on the LPUF-51-E/LPUI-51-E/LPUI-51-S/LPUI-51-CM/LPUF-120/LPUF-120-B/LPUF-120-E/LPUI-102-E/LPUI-120/LPUI-120-B/LPUI-120-L/LPUI-52-E/LPUI-120-E/LPUI-120-CM/LPUF-240/LPUF-240-B/LPUF-240-E/LPUI-240/LPUI-240-B/LPUI-240-CM/LPUI-240-L/LPUF-480/LPUF-480-B/LPUI-480/LPUI-480-B/LPUI-480-L/LPUF-480-E/LPUI-480-CM/LPUF-400-Eboards support source cloning-based PIM FRR. Traffic in other multicast groups is forwarded at Layer 3, and no source-cloned entries are generated.

Source cloning-based PIM FRR supports only the LPUI-200/LPUI-200-L/LPUF-200/LPUF-200-B/LPUI-1T/LPUI-1T-B/LPUI-1T-L/LPUI-1T-CM boards.

NA

Only certain multicast groups on theLPUI-200/LPUI-200-L/LPUF-200/LPUF-200-B/LPUI-1T/LPUI-1T-B/LPUI-1T-L/LPUI-1T-CM boards support source cloning-based PIM FRR. Traffic in other multicast groups is forwarded at Layer 3, and no source-cloned entries are generated.

Source cloning-based PIM FRR supports only the LPUI-2T/LPUI-2T-B/LPUI-2T-CM boards.

NA

Only certain multicast groups on the LPUI-2T/LPUI-2T-B/LPUI-2T-CM boards support source cloning-based PIM FRR. Traffic in other multicast groups is forwarded at Layer 3, and no source-cloned entries are generated.

Source cloning-based PIM FRR supports MVPN in Rosen mode and requires integrated MVPN service boards.

NA

In distributed mode, if the link connecting to the inbound interface of multicast traffic fails, the inbound interface is reselected. During the inbound interface reselection, packets are discarded.

The device where source cloning-based PIM FRR is deployed must have at least two paths to protect traffic.

NA

If there is only one path, PIM FRR does not work.

If the inbound interface for source cloning-based PIM FRR traffic is a trunk interface, a trunk member interface change may trigger PIM FRR, causing a link switchover.

NA

Multicast traffic is switched or lost.

In a scenario where a second fault occurs before the first fault is completely rectified (traffic interruption is also a fault), source cloning-based PIM FRR does not support fast switchover. Both primary and secondary links fail:
  • If strict explicit paths are used, protocol convergence is unavailable. As a result, traffic is interrupted.
  • If loose explicit paths are configured and there are normal links that meet the requirements of loose explicit path planning once primary and secondary links are faulty, services are restored based on protocol convergence, and fast switchover is not supported.

NA

Fast switchover cannot be performed.

Source cloning-based PIM FRR occupies one more copy of bandwidth than PIM FRR in another mode.

NA

Upstream multicast traffic occupies one more copy of bandwidth.

Translation
Download
Updated: 2019-01-03

Document ID: EDOC1100055017

Views: 44495

Downloads: 97

Average rating:
This Document Applies to these Products
Related Version
Related Documents
Share
Previous Next