Got it

IS-IS Local MT

717 0 0 0 1

IS-IS Local MT

IGP local multicast-topology (MT) creates a multicast topology on the local device, without affecting the protocol packets exchanged between devices. When the outbound interface calculated by an IGP for a route is a TE tunnel interface enabled with IGP Shortcut (AA), IGP local MT calculates one or a group of physical outbound interfaces for the route.

On a network with both multicast and a TE tunnel deployed, multicast may fail to function because an IGP, such as IS-IS and OSPF, may adopt the TE tunnel interface as the outbound interface of a unicast route.

IS-IS local MT is thus introduced to address the conflict between the TE tunnel and multicast. IS-IS local MT is configured at the ingress of a TE tunnel, and the protocol packets exchanged between devices are not affected. Thus, it is easy to configure and no interconnectivity problem arises. IS-IS local MT is an effective solution to the backbone network where a TE tunnel and multicast are deployed simultaneously.

Background

When multicast and an MPLS TE tunnel are deployed in a network simultaneously, the multicast function may be affected by the TE tunnel.

This is because after the TE tunnel is enabled with IGP Shortcut (AA), the outbound interface of a route calculated by an IGP is not the actual physical interface but a TE tunnel interface. According to the unicast route to the multicast source address, a router sends a Report message through a TE tunnel interface. Routers spanned by the TE tunnel cannot sense the Report message, so multicast forwarding entries cannot be created. The TE tunnel is unidirectional, so multicast data packets sent by the multicast source are sent to the routers spanned by the tunnel through the related physical interfaces. The routers do not have any multicast forwarding entry. Thus, the multicast data packets are discarded. Figure 1 shows the networking.

Figure 1 TE tunnel scenario 
fig_dc_vrp_feature_new_00605301.png

RouterA, RouterB, RouterC, RouterD, and RouterE are Level-2 routers. The routers run IS-IS to implement interconnection. The multicast services are normal. A unidirectional MPLS TE tunnel is set up between RouterB and RouterD. The MPLS TE tunnel is enabled with IGP Shortcut (AA). When you view the multicast routing table on RouterC spanned by the TE tunnel, you cannot find any multicast forwarding entry. Thus, the multicast services are interrupted.

The process of transmitting multicast packets between the client and the multicast server is as follows:

  1. To join a multicast group, the client sends a Report message to RouterA. RouterA then sends a Join message to RouterB.

  2. When the Join message reaches RouterB, RouterB uses Tunnel 1/0/0 as the Reverse Path Forwarding (RPF) interface and forwards the message to RouterC through GE 2/0/0 by using the MPLS label.

  3. The Join message is forwarded with the MPLS label, so RouterC just forwards the message and does not create a multicast routing entry. In the topology shown in Figure 1RouterC is the penultimate hop of the MPLS forwarding. RouterC pops out the MPLS label, and then forwards the Join message to RouterD through GE 2/0/0.

  4. After receiving the Join message, RouterD creates a multicast forwarding entry. The inbound interface is GE 2/0/0 and the outbound interface is GE 1/0/0. RouterD then forwards the message to RouterE. The SPT is thus set up.

  5. When the multicast source sends the traffic to RouterD, RouterD forwards the traffic to RouterC. RouterC does not create any forwarding entry in advance. Therefore, the traffic is discarded and the multicast service is interrupted.

    As described in the preceding process of transmitting multicast packets, the forwarding of multicast packets relies on the unicast routing table and the TE tunnel is unidirectional. Therefore, the multicast packets are discarded. This problem can be avoided by using the following methods:

    • Manually configuring static multicast routes to guide the forwarding of multicast packets

    • Configuring a bidirectional TE tunnel

      In this case, the returned multicast packets can be sent by using the same tunnel. Routers spanned by the TE tunnel use the tunnel to transmit multicast packets.

    • Configuring the Multicast Border Gateway Protocol (MBGP) to separate the unicast topology from the multicast topology

      MBGP provides the topology that does not contain the TE tunnel for multicast separately. Multicast is used to perform RPF check on MBGP routes.

    • Configuring local MT

    The preceding methods are used to prevent interruption of multicast services. The disadvantage of the first three methods is that there are numerous manual configurations required. In a complex network, this results in increased planning, configuration, and maintenance tasks. In this kind of network environment, local MT needs to be configured.

Implementation Principle

The NE5000E supports local MT. As a result, the case that the multicast services are interrupted when multicast and the MPLS TE tunnel enabled with IGP Shortcut (AA) are deployed can be avoided.

After local MT is enabled, the router at the ingress of a TE tunnel creates a separate multicast IGP (MIGP) routing table to store the physical interfaces to which the TE tunnel corresponds. This ensures that multicast protocol packets are correctly forwarded. The correct routing entries are created in the multicast routing table (MRT). Figure 2 shows the networking.

Figure 2 Local MT Topology 
fig_dc_vrp_feature_new_00605302.png
  • Create an MIGP routing table.

    Multicast protocol packets are forwarded according to the unicast routing table. After local MT is enabled on RouterB, RM creates separate MIGP routing tables for multicast protocols. When the outbound interface of a route is a TE tunnel interface, an IGP calculates out the actually physical outbound interface for the route and adds the outbound interface to the MIGP routing table.

  • Guide the forwarding of multicast protocol packets.

    Before forwarding a multicast protocol packet, a router needs to search the unicast routing table. If the router finds that the next hop is the TE tunnel, the router continues to search the MIGP routing table for the related physical outbound interface to guide the forwarding of the multicast protocol packet.

If the outbound interface of multicast source 192.168.3.2/24 is TE tunnel 1/0/0, the physical outbound interface of the route calculated by IS-IS is GE 2/0/0. IS-IS adds the route to the MIGP routing table. The multicast services are thus not affected by the TE tunnel. Multicast packets are forwarded through the physical outbound interfaces according to the MIGP routing table for general IP forwarding. The related routing entries are created in the MRT. Multicast data packets are thus correctly forwarded.

Application Environment

The principle of local MT is to create a separate multicast topology on the local device, without affecting the protocol packets exchanged between devices. The topology in Figure 2 is used as an example. Figure 3 shows the flows for (S, G) Join messages and multicast data packets after local MT is configured on RouterB.

Figure 3 Local MT addressing the conflict between multicast and a TE tunnel 
fig_dc_vrp_feature_new_00605303.png

RouterB creates a separate MIGP routing table. If the outbound interface of the route 10.10.10.10/24 calculated by an IGP is Tunnel 6/0/0, the actual physical outbound interface calculated by the IGP will be GE 6/0/1. The multicast services are not affected by the TE tunnel.


  • x
  • convention:

Comment

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

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

Login

Block
Are you sure to block this user?
Users on your blacklist cannot comment on your post,cannot mention you, cannot send you private messages.
Reminder
Please bind your phone number to obtain invitation bonus.
Information Protection Guide
Thanks for using Huawei Enterprise Support Community! We will help you learn how we collect, use, store and share your personal information and the rights you have in accordance with Privacy Policy and User Agreement.