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

Configuration Guide - IP Multicast

CloudEngine 8800, 7800, 6800, and 5800 V200R005C00

This document describes the configurations of IP multicast, including IP multicast basics, IGMP, MLD, PIM (IPv4), PIM (IPv6), MSDP, multicast VPN, multicast route management (IPv4), multicast route management (IPv6), IGMP snooping, MLD snooping, static multicast MAC address, multicast VLAN, multicast network management.
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).
IPv4 Layer 3 Multicast Over VXLAN

IPv4 Layer 3 Multicast Over VXLAN

Currently, IPv4 Layer 3 multicast over VXLAN is supported only in distributed gateway scenarios. The following describes how this feature works at the control and data forwarding planes, and how its reliability is ensured.

Control Plan Establishment

A VXLAN network with distributed gateways uses BGP EVPN routes to dynamically establish VXLAN tunnels and transmit host MAC routes or host IP routes, thereby implementing Layer 2 and Layer 3 communication between devices of the same tenant. To implement Layer 3 multicast in this scenario, the NG MVPN mechanism must be introduced on the control plane so that multicast routing information can be transmitted on the VXLAN network. Multicast entries can then be established on the VXLAN network to guide multicast data forwarding.

NOTE:

The CE series switches do not support the NG MVPN function. The NG MVPN mechanism is partly introduced to the control plane of the IPv4 Layer 3 multicast over VXLAN function so that multicast routing information can be transmitted on the VXLAN network.

Basic NG MVPN Concepts

Figure 14-1 shows the basic network model of NG MVPN in a distributed VXLAN gateway scenario. Table 14-1 describe the basic concepts involved in this model.

Figure 14-1 Basic NG MVPN network model
Table 14-1 Basic concepts

Concept

Description

Leaf

A VXLAN gateway, logically used as the VTEP of a VXLAN tunnel. A leaf is functionally equivalent to a provider edge (PE) on an NG MVPN. All VPN processings are performed on this device.

Spine

A transparent transmission device that focuses on IP forwarding on a VXLAN network. A spine is functionally equivalent to a provider (P) on an NG MVPN. This device has the BGP EVPN and basic IP forwarding capabilities but does not maintain VPN information.

Customer edge (CE)

Provides an interface to connect to a leaf. A CE generally does not detect the existence of VPNs. A PIM network is usually deployed between a leaf and a CE so that multicast receivers can access a VXLAN-based NG MVPN.

BGP MVPN peer

Exchanges BGP MVPN routes with other peers to transmit user join information for generation of multicast entries. An NG MVPN uses BGP to transmit VPN multicast routes. To enable different leaf nodes on the same NG MVPN to exchange BGP MVPN routes, a BGP MVPN peer relationship must be established between these leaf nodes.

Inclusive-provider multicast service interface (I-PMSI) tunnel

A logical tunnel used for a public network to carry VPN multicast data. On an NG MVPN, the information that a leaf uses to create a public network tunnel is carried by a new route attribute defined by BGP. This attribute is PMSI. An I-PMSI tunnel connects all PEs on the same NG MVPN. Multicast data sent over an I-PMSI tunnel can be received by all PEs on the NG MVPN.

The VXLAN tunnel between leaf nodes is an I-PMSI tunnel on the NG MVPN.

PIM Join (multicast member join)

PIM Join messages that are converted into BGP MVPN routes on leaf nodes and sent to the leaf or RP on the multicast source side, instructing the leaf nodes to generate multicast entries. There are two types of PIM Join messages:

  • If a multicast source is specified when a multicast member joins a multicast group, the PIM (S, G) Join message is used.

  • If no multicast source is specified when a multicast member joins a multicast group, the PIM (*, G) Join message is used.

BGP MVPN Peer Establishment and Route Transmission

MVPN Membership Autodiscovery

On a VXLAN-based NG MVPN, each leaf node needs to discover other leaf nodes that belong to the same MVPN. This process is called MVPN membership autodiscovery. An NG MVPN uses BGP to implement this process. To support MVPN membership autodiscovery, BGP defines a new address family, the BGP-MVPN address family. After the BGP-MVPN address family is enabled on leaf nodes, they can automatically negotiate to establish BGP peer relationships in the BGP-MVPN address family. The implementation is as follows:

Leaf nodes on the same MVPN send BGP Update messages to each other to exchange MVPN information because MVPN information is carried in the Network Layer Reachable Information (NLRI) field of BGP Update messages. The NLRI carrying MVPN information is also called MVPN NLRI. Figure 14-2 and Table 14-2 describes the NLRI format and fields, respectively.

Figure 14-2 MVPN NLRI format
Table 14-2 MVPN NLRI fields

Field

Description

Route type

Type of an MVPN route. For details, see Table 14-3.

Length

Length of the Route type specific field in the MVPN NLRI.

Route type specific

MVPN route information. The value of this field depends on the Route type field. For details, see Table 14-3.

Table 14-3 describes the types and functions of MVPN NLRI. Types 1 and 5 are called MVPN Auto-Discovery (A-D) routes, which are used to automatically discover MVPN members. After leaf nodes on an MVPN exchange type 1 routes, they automatically establish a BGP MVPN peer relationship.

Table 14-3 MVPN NLRI Types

Type

Name

Function

Route type specific Field Format

1

Intra-AS I-PMSI A-D route

Used for MVPN membership autodiscovery in intra-AS scenarios and initiated by MVPN-capable leaf nodes.

Field description:

  • RD: route distinguisher, an 8-byte field in a VPN-IPv4 address. An RD and a 4-byte IPv4 address prefix form a VPN-IPv4 address, which is used to differentiate the IPv4 prefixes using the same address space in different VPN instances.

  • Originating router's IP address: IP address of the device that originates A-D routes. In application, this field is the MVPN ID of the router that originates BGP A-D routes.

5

Source Active A-D route

Used by a leaf to notify other leaf nodes on the same MVPN of multicast source information.

Field description:

  • RD: RD of the VPN instance on the leaf connected to the multicast source.

  • Multicast source length: length of a multicast source address. The value is 32 if the multicast group address is an IPv4 address.

  • Multicast source: multicast source address

  • Multicast group length: length of a multicast group address. The value is 32 if the multicast group address is an IPv4 address.

  • Multicast group: multicast group address.

6

Shared Tree Join route

Used in (*, G) scenarios. For VPN PIM-SM, (*, G) join is also called (C-*, C-G) PIM join, where C indicates customer, namely, a VPN scenario.

When a receiver-side leaf receives a (C-*, C-G) PIM Join message, it converts the Join message into a Shared Tree Join route and then sends the route to other leaf nodes that have established BGP MVPN peer relationships with the receiver-side leaf. Through other leaf nodes, the route can reach the RP.

Field description:

  • RD: RD of the VPN instance on the leaf connected to the multicast source.

  • Source AS: Source AS Extended Community of the unicast route to the multicast source.

  • Multicast source length: length of a multicast source address. The value is 32 if the multicast group address is an IPv4 address.

  • Multicast source: multicast source address

  • Multicast group length: length of a multicast group address. The value is 32 if the multicast group address is an IPv4 address.

  • Multicast group: multicast group address.

NOTE:

Shared Tree Join routes and Source Tree Join routes have the same NLRI format. But for (C-*, C-G) joins, a multicast source address is an RP address.

7

Source Tree Join route

Used in (S, G) scenarios. For VPN PIM-SSM, (S, G) join is also called (C-S, C-G) PIM join, where C indicates customer, namely, a VPN scenario.

When a receiver-side leaf receives a (C-S, C-G) PIM Join message, it converts the Join message into a Source Tree Join route and then sends the route to the leaf at the multicast source side that has established BGP MVPN peer relationships with the receiver-side leaf.

BGP MVPN Route Information

Table 14-3 shows the BGP MVPN routes exchanged between leaf nodes on the same MVPN. Type 1 routes are exchanged between leaf nodes for BGP MVPN peer relationship establishment. Type 5 routes are used to advertise active multicast source information. Types 6 and 7 routes are called C-multicast routes. C indicates customer. Therefore, C-multicast routes indicate multicast routes from VPNs. They are used for VPN user joining and multicast entry generation. For details about types 5, 6, and 7 BGP MVPN routes, see Multicast Member Join Process.

MVPN Targets

MVPN targets are used to control MVPN A-D route advertisement. MVPN targets function in a similar way as VPN targets for unicast VPN and are also classified into two types:
  • Export MVPN target: After being added to an MVPN instance of a local leaf, an export MVPN target is advertised along with an MVPN A-D route.
  • Import MVPN target: After receiving an MVPN A-D route from another leaf, a leaf matches the export MVPN target of the route against the import MVPN targets of its VPN instances. If the export MVPN target matches the import MVPN target of a VPN instance, the leaf accepts the MVPN A-D route and records the sender leaf as an MVPN member. If the export MVPN target does not match the import MVPN target of any VPN instance, the leaf drops the MVPN A-D route.
NOTE:

By default, if you do not configure MVPN targets for an MVPN, MVPN A-D routes carry the VPN targets used for unicast VPN. If an MVPN and a unicast VPN share the same network topology, you do not need to configure MVPN targets. Otherwise, configuring MVPN targets is required.

MVPN Extended Community Attributes

MVPN extended community attributes, which are used to control the advertisement and receiving of BGP C-multicast routes, can be:
  • Source AS Extended Community: carried in the BGP EVPN routes advertised by leaf nodes. This attribute is an AS-type attribute and is mainly used in inter-AS scenarios.

  • VRF Route Import Extended Community: carried in BGP EVPN routes advertised by a leaf to other leaf nodes. When a receiver leaf sends a C-multicast route to a sender leaf, the receiver leaf attaches this attribute to the route. When there are multiple sender leaf nodes, each sender leaf that receives a C-multicast route can determine, according to this attribute, whether the C-multicast route should be processed by itself and which VPN routing table that the C-multicast route should be installed into.

    The value of the VRF Route Import extended community attribute is in the format of Administrator field: Local Administrator field. Administrator field uses the local MVPN ID as its value, whereas Local Administrator field uses the local VPN instance ID of a sender PE as its value.

I-PMSI Tunnel Establishment

On an NG MVPN, an I-PMSI tunnel is a logical tunnel used by the public network to carry VPN multicast data. When establishing an I-PMSI tunnel, you must specify the P-tunnel type. Currently, only VXLAN tunnels can serve as P-tunnels. For details about how to establish a VXLAN tunnel, see "Distributed VXLAN Gateway Deployment Using BGP EVPN" in the VXLAN section.

Multicast Member Join Process

After leaf nodes establish a BGP MVPN peer relationship, they can use BGP MVPN routes to transmit the join information of VPN multicast members. The following example describes how a multicast receiver joins a multicast group in PIM (S, G) and PIM (*, G) modes.

PIM (S, G) Join

Figure 14-3 describes how Leaf 2 initiates a PIM (S, G) Join request to Leaf 1 for the receiver to join a multicast group.

Figure 14-3 Time sequence for joining a multicast group in PIM (S, G) mode

For details about the process of joining a multicast group, see Table 14-4.

Table 14-4 Multicast member join process

Step

Device Name

Key Action

1

Leaf 1

After Leaf 1 generates a unicast route destined for the multicast source, Leaf 1 converts this route to a BGP EVPN route, adds the Source AS Extended Community and VRF Route Import Extended Community to this route, and advertises this route to Leaf 2.

2

Leaf 2

After Leaf 2 receives the BGP EVPN route from Leaf 1, Leaf 2 matches the export VPN target of the route against its local import VPN target:
  • If the two targets match, Leaf 2 accepts the BGP EVPN route and locally stores the Source AS Extended Community and VRF Route Import Extended Community values carried in this route for later generating a C-multicast route.
  • If the two targets do not match, Leaf 2 drops the BGP EVPN route.

3

Leaf 2

After Leaf 2 receives an IGMP join request, Leaf 2 generates a PIM-SSM Join message.

4

Leaf 2

After Leaf 2 generates a PIM-SSM Join message:
  • Leaf 2 generates a C-multicast route based on the locally stored Source AS Extended Community and VRF Route Import Extended Community values. The RT-import attribute of this route is set to the locally stored VRF Route Import Extended Community value.
  • Leaf 2 generates a multicast entry. In this entry, the downstream interface is the interface that receives the PIM-SSM Join message. After searching for the VPN unicast route to the multicast source, Leaf 2 finds that the upstream device on the path to the multicast source is Leaf 1. Leaf 2 then sends the PIM-SSM Join message to Leaf 1 through the C-multicast route.

5

Leaf 2

Sends the C-multicast route to Leaf 1 that has established a BGP MVPN peer relationship with Leaf 2.

6

Leaf 1

After receiving the C-multicast route, Leaf 1 performs the following operations:
  1. Checks the Administrator field and Local Administrator field values in the RT-import attribute of the C-multicast route. After Leaf 1 confirms that the Administrator field value is the same as its local MVPN ID, Leaf 1 accepts the C-multicast route.
  2. Determines to which VPN instance routing table the C-multicast route should be added based on the Local Administrator field value in the RT-import attribute of the route.
  3. Processes the C-multicast route and adds it to the corresponding VPN instance routing table.
  4. Converts the C-multicast route into a PIM-SSM Join message and creates a VPN multicast entry to guide multicast data traffic forwarding. The downstream interface of the multicast entry is a Through-BGP interface. The forwarding plane is a VXLAN tunnel.

After that, the multicast receiver successfully joins the multicast group, and Leaf 1 can send multicast traffic to Leaf 2.

PIM (*, G) Join

Table 14-5 lists the implementation modes of PIM (*, G) multicast joining.

Table 14-5 Implementation modes of PIM (*, G) multicast joining

Implementation Mode

Principle

Advantage

Disadvantage

Across the public network
PIM (*, G) entries are transmitted over the VXLAN tunnel on the public network to a remote leaf node. The multicast group join process includes:
  • Rendezvous point tree (RPT) construction (see Table 14-6 for more information)
  • Switching from an RPT to a shortest path tree (SPT) (see Table 14-7 for more information)

In this mode, the VPN routes from each device to the RP must be reachable.

The VPN RP can be configured either on a leaf or on a CE.

  • The RPT-to-SPT switching may occur on the public network. Therefore, leaf nodes need to maintain a lot of route state information.
  • Currently, a VPN RP can be only static.
Not across the public network

PIM (*, G) entries are converted to PIM (S, G) entries before being transmitted to a remote leaf across the public network.

In this mode, if different PIM-SM BSR domains are divided, the VPN routes from each device must be reachable to the local RP. If BSR domains are not divided, the VPN routes from each device must be reachable to the RP.

  • PIM (*, G) entries are not transmitted across the public network. Therefore, the RPT-to-SPT switching does not occur on the public network, which reduces the leaf processing complexity and reduces status maintenance information on leaf nodes.
  • The VPN RP can be either static or dynamic.

The VPN RP can be configured either on a leaf or on a CE. If the VPN RP is configured on a CE, the CE needs to set up an MSDP peer relationship with its connected leaf.

NOTE:

The advertisement of BGP EVPN routes during multicast joining in PIM (*, G) mode is similar to that in PIM (S, G) mode. For more information, see Table 14-4.

  • PIM (*, G) multicast joining across the public network

    In this mode, the implementation is similar irrespective of whether an RP is configured on a leaf or a CE. The following describes the implementation when an RP is configured on a CE.

    On the network shown in Figure 14-4, an RP is deployed on CE3. Figure 14-5 and Table 14-6 respectively show the time sequence and procedure for establishing an RPT.

    Figure 14-4 Networking for PIM (*, G) multicast joining
    Figure 14-5 Time sequence for establishing an RPT
    Table 14-6 Procedure for establishing an RPT

    Step

    Device Name

    Key Action

    1

    CE2

    After CE2 receives an IGMP join request, CE2 sends a PIM (*, G) Join message to Leaf 2.

    2

    Leaf 2

    After Leaf 2 receives the PIM (*, G) Join message, PE2 generates a PIM (*, G) entry. In this entry, the downstream interface is the interface that receives the PIM (*, G) Join message. After searching for the unicast route to the RP, Leaf 2 finds that the upstream device on the path to the RP is Leaf 3. Leaf 2 then constructs a C-multicast route (Shared Tree Join route) and sends the route to its BGP MVPN peer Leaf 3.

    NOTE:

    The C-multicast route construction process is similar to that in PIM(S, G) Join mode. For details, see Table 14-4.

    3

    Leaf 3

    After receiving the C-multicast route (Shared Tree Join route), Leaf 3 performs the following operations:
    1. Checks the Administrator field and Local Administrator field values in the RT-import attribute of the C-multicast route. After Leaf 3 confirms that the Administrator field value is the same as its local MVPN ID, Leaf 3 accepts the C-multicast route.
    2. Determines to which VPN instance routing table the C-multicast route should be added based on the Local Administrator field value in the RT-import attribute of the route.
    3. Adds the C-multicast route to the corresponding VPN instance routing table and creates a VPN multicast entry to guide multicast traffic forwarding. In the multicast entry, the downstream interface is a Through-BGP interface. The forwarding plane is a VXLAN tunnel.
    4. Converts the C-multicast route to a PIM (*, G) Join message and sends this message to CE3.

    4

    CE3

    Upon receipt of the PIM (*, G) Join message, CE3 generates a PIM (*, G) entry. In this entry, the downstream interface is the interface that receives the PIM (*, G) Join message. Then, an RPT rooted at CE3 and with CE2 as its leaf is established.

    5

    CE1

    After CE1 receives multicast traffic from the multicast source, CE1 sends a PIM Register message to CE3.

    6

    CE3

    Upon receipt of the PIM Register message, CE3 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry. Meanwhile, CE3 sends multicast traffic to Leaf 3.

    7

    Leaf 3

    Upon receipt of the multicast traffic, Leaf 3 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry. Because the outbound interface in the PIM (*, G) entry is a Through-BGP interface (with the forwarding plane being a VXLAN tunnel), the multicast data is guided to the I-PMSI tunnel, namely, the VXLAN tunnel.

    8

    Leaf 2

    Upon receipt of the multicast traffic, Leaf 2 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry.

    9

    CE2

    Upon receipt of the multicast traffic, CE2 sends the multicast traffic to the multicast receiver.

    When the multicast traffic sent by the multicast server exceeds the threshold set on CE2, CE2 initiates RPT-to-SPT switching. If no threshold is configured on CE2, CE2 immediately switches to the SPT. Figure 14-6 shows the time sequence for switching an RPT to an SPT. Table 14-7 describes the procedure for switching an RPT to an SPT.

    NOTE:

    When the receiver leaf receives multicast traffic transmitted along the RPT, the receiver leaf immediately initiates RPT-to-SPT switching. The RPT-to-SPT switching process on the receiver leaf is similar to that on CE2.

    Figure 14-6 Time sequence for RPT-to-SPT switching
    Table 14-7 Procedure for RPT-to-SPT switching

    Step

    Device Name

    Key Action

    1

    CE2

    After the received multicast traffic exceeds the set threshold, CE2 initiates RPT-to-SPT switching by sending a PIM (S, G) Join message to Leaf 2.

    2

    Leaf 2

    Upon receipt of the PIM (S, G) Join message, PE2 updates the outbound interface status in its PIM (S, G) entry and switches the PIM (S, G) entry to the SPT. Then, Leaf 2 searches its multicast routing table for a route to the multicast source. After Leaf 2 finds that the upstream device on the path to the multicast source is Leaf 1, Leaf 2 sends a C-multicast route (Source Tree Join route) to Leaf 1.

    3

    Leaf 1

    Upon receipt of the C-multicast route (Source Tree Join route), Leaf 1 generates a PIM (S, G) entry and sends a PIM (S, G) Join message to CE1.

    4

    CE1

    Upon receipt of the PIM (S, G) Join message, CE1 generates a PIM (S, G) entry. Then, the RPT-to-SPT switching is complete, and CE1 can send multicast traffic to Leaf 1.

    5

    Leaf 1

    To prevent duplicate multicast traffic, Leaf 1 carries the PIM (S, G) entry information in a Source Active AD route and sends the route to all its BGP peers.

    6

    Leaf 3

    Upon receipt of the Source Active AD route, Leaf 3 records the route. After RPT-to-SPT switching, Leaf 3, the ingress of the VXLAN tunnel for the RPT, deletes received multicast traffic, generates the (S, G, RPT) state, and sends a PIM (S, G, RPT) Prune to its upstream device for deleting PIM (S, G) entry. Meanwhile, Leaf 3 updates its VPN multicast routing entries and stops forwarding multicast traffic.

    NOTE:

    To prevent packet loss during RPT-to-SPT switching, the PIM (S, G, RPT) Prune operation is performed after a short delay that ensures Leaf 2 completes RPT-to-SPT switching.

    7

    Leaf 2

    Upon receipt of the Source Active AD route, Leaf 2 records the route. Leaf 2 finishes RPT-to-SPT traffic switching. And Leaf 2 can receive multicast traffic from Leaf 1.

  • PIM (*, G) multicast joining without crossing the public network

    • Scenario 1: An RP is deployed on leaf nodes.

      On the network shown in Figure 14-4, deploy an RP on Leaf 1 and Leaf 2. Figure 14-7 shows the time sequence for joining a multicast group. Table 14-8 describes the procedure for joining a multicast group.

      Figure 14-7 Time sequence for joining a multicast group when an RP is deployed on leaf nodes
      Table 14-8 Procedure for joining a multicast group when an RP is deployed on leaf nodes

      Step

      Device Name

      Key Action

      1

      CE2

      After CE2 receives an IGMP join request, CE2 sends a PIM (*, G) Join message to Leaf 2.

      2

      Leaf 2

      Upon receipt of the PIM (*, G) Join message, Leaf 2 generates a PIM (*, G) entry. Because Leaf 2 is the RP, PE2 does not send the C-multicast route (Shared Tree Join route) to other devices. Then, an RPT rooted at Leaf 2 and with CE2 as the leaf node is established.

      3

      CE1

      After CE1 receives multicast traffic from the multicast source, CE1 sends a PIM Register message to Leaf 1.

      4

      Leaf 1

      Upon receipt of the PIM Register message, Leaf 1 generates a PIM (S, G) entry.

      5

      Leaf 1

      Leaf 1 sends a Source Active AD route to all its BGP MVPN peers.

      6

      Leaf 2

      Upon receipt of the Source Active AD route, Leaf 2 generates a PIM (S, G) entry, which inherits the outbound interface of the previously generated PIM (*, G) entry.

      7

      Leaf2

      Leaf 2 initiates RPT-to-SPT switching and sends a C-multicast route (Source Tree Join route) to Leaf 1.

      8

      Leaf 1

      Upon receipt of the C-multicast route (Source Tree Join route), Leaf 1 imports multicast traffic to the I-PMSI tunnel (VXLAN tunnel) based on the corresponding VPN multicast forwarding entry. Then, multicast traffic is transmitted over the I-PMSI tunnel to CE2.

    • Scenario 2: An RP is deployed on CEs.

      On the network shown in Figure 14-4, an RP is deployed on CE2 and CE3, an MSDP peer relationship is established between CE2 and Leaf 2 and between CE3 and Leaf 3. Figure 14-8 shows the time sequence for joining a multicast group. Table 14-9 describes the procedure for joining a multicast group.

      Figure 14-8 Time sequence for joining a multicast group when an RP is deployed on CEs
      Table 14-9 Procedure for joining a multicast group when an RP is deployed on CEs

      Step

      Device Name

      Key Action

      1

      CE2

      After CE2 receives an IGMP join request, CE2 generates a PIM (*, G) Join message. Because CE2 is the RP, CE2 does not send the PIM (*, G) Join message to its upstream device.

      2

      CE1

      After CE1 receives multicast traffic from the multicast source, CE1 sends a PIM Register message to CE3.

      3

      CE3

      Upon receipt of the PIM Register message, CE3 generates a PIM (S, G) entry.

      4

      CE3

      CE3 carries the PIM (S, G) entry information in an MSDP SA message and sends the message to its MSDP peer, Leaf 3.

      5

      Leaf 3

      Upon receipt of the MSDP SA message, Leaf 3 generates a PIM (S, G) entry.

      6

      Leaf 3

      Leaf 3 carries the PIM (S, G) entry information in a Source Active AD route and sends the route to other leaf nodes.

      7

      Leaf 2

      Upon receipt of the Source Active AD route, Leaf 2 learns the PIM (S, G) entry information carried in the route. Then, Leaf 2 sends an MSDP SA message to transmit the PIM (S, G) entry information to its MSDP peer, CE2.

      8

      CE2

      Upon receipt of the MSDP SA message, CE2 learns the PIM (S, G) entry information carried in the message and generates a PIM (S, G) entry. CE2 initiates a PIM (S, G) join request to the multicast source. This implementation process is similar to that in PIM (S, G) Join mode. During this process, Leaf 1 also generates a PIM (S, G) entry. Finally, CE2 forwards the multicast traffic to the multicast receiver.

Data Packet Forwarding

After a VXLAN-based NG MVPN is established, a multicast source can provide MVPN services for users on the VXLAN network after multicast users join a multicast group. Multicast data forwarding involves the following scenarios:

  • A multicast source is on a VXLAN overlay network while multicast receivers are on an external network.

  • A multicast source is on an external network while multicast receivers are on a VXLAN overlay network.

  • Both a multicast source and multicast receivers are on a VXLAN overlay network.

The following uses Figure 14-9 and Figure 14-10 to show how IP multicast data is encapsulated and forwarded from a multicast source to multicast receivers in the scenario where the multicast source and receivers both are on the VXLAN overlay network. The implementation processes of the other two scenarios are similar to that of this example. The difference is that when multicast data is forwarded outside the VXLAN, multicast data needs to be forwarded based on multicast entries on the external network.

Figure 14-9 Typical IPv4 Layer 3 multicast over VXLAN networking
Figure 14-10 Multicast data forwarding process

Table 14-10 shows the multicast data forwarding process.

Table 14-10 Multicast data forwarding process

Step

Device Name

Action

Multicast Forwarding Table Information

1

Leaf 1

Receives IP multicast data traffic from the multicast source, searches for the VPN forwarding entry corresponding to the (C-S, C-G) in the multicast forwarding table of the VPN instance, and encapsulates a VXLAN packet header for the private IP multicast data traffic. In the header, the VNI is the Layer 3 VNI bound to the VPN instance, and the outer destination address is the BUM multicast replication address (for example, 225.0.0.1). Packets are then guided to the VXLAN tunnel. Based on the BUM packet's multicast forwarding entry, Leaf 1 sends the packet to the Spine.

NOTE:

For details about BUM multicast replication, see BUM packet forwarding in "Distributed VXLAN Gateway Deployment Using BGP EVPN".

VPN-Instance: mvpn
(C-S, C-G):(192.168.1.2, 232.1.1.1)
Upstream interface: Vbdif1
Downstream interface(s) information:
pseudo
Protocol: BGP

VPN-Instance: public net
(S, G):(1.1.1.1, 225.0.0.1)
Upstream interface: LoopBack1
Downstream interface(s) information: 
Port1

(S, G):(2.2.2.2, 225.0.0.1)
Upstream interface: Register
Downstream interface(s) information: 
Nve

(S, G):(3.3.3.3, 225.0.0.1)
Upstream interface: Register
Downstream interface(s) information: 
Nve

2

Spine

After receiving the VXLAN packet, the spine replicates the multicast data based on the multicast forwarding entry of the BUM packet and forwards the packet to Leaf 2 and Leaf 3.

VPN-Instance: public net
(S, G):(1.1.1.1, 225.0.0.1)
Upstream interface: port1
Downstream interface(s) information: 
Port2
Port3

(S, G):(2.2.2.2, 225.0.0.1)
Upstream interface: port2
Downstream interface(s) information: 
Port1
Port3

(S, G):(3.3.3.3, 225.0.0.1)
Upstream interface: port3
Downstream interface(s) information: 
Port1
Port2

3

Leaf 2/Leaf 3

After receiving the VXLAN packet, Leaf 2 and Leaf 3 decapsulate the VXLAN packet. Based on the mapping between the Layer 3 VNI and VPN instance, they search for the VPN forwarding entries corresponding to the (C-S, C-G) in the multicast forwarding table of the VPN instance, and then forward the IP multicast data traffic to receivers through the Layer 2 sub-interfaces bound to the BD.

Leaf 2:

VPN-Instance: mvpn
(C-S, C-G):(192.168.1.2, 232.1.1.1)
Upstream interface: through-BGP
Downstream interface(s) information:
Vbdif1

VPN-Instance: public net
(S, G):(1.1.1.1, 225.0.0.1)
Upstream interface: Register
Downstream interface(s) information: 
Nve

(S, G):(2.2.2.2, 225.0.0.1)
Upstream interface: LoopBack1
Downstream interface(s) information: 
Port1

(S, G):(3.3.3.3, 225.0.0.1)
Upstream interface: Register
Downstream interface(s) information: 
Nve

Leaf 3:

VPN-Instance: mvpn
(C-S, C-G):(192.168.1.2, 232.1.1.1)
Upstream interface: through-BGP
Downstream interface(s) information:
Vbdif2

VPN-Instance: public net
(S, G):(1.1.1.1, 225.0.0.1)
Upstream interface: Register
Downstream interface(s) information: 
Nve

(S, G):(2.2.2.2, 225.0.0.1)
Upstream interface: Register
Downstream interface(s) information: 
Nve

(S, G):(3.3.3.3, 225.0.0.1)
Upstream interface: Loopback1
Downstream interface(s) information: 
Port1

Access Reliability

Similar to unicast, the access reliability of virtual extensible LAN (VXLAN)-based Layer 3 multicast is implemented through access gateway stacking or multichassis link aggregation group (M-LAG) (active-active gateways). In gateway stacking, stacked devices are logically equivalent to one device. The process of multicast traffic forwarding is similar to that of a single device, and is not explained here. This section describes the multicast traffic forwarding process when the M-LAG (active-active gateways) is deployed on the access side.

There are 3 network working scenarios with different locations of the multicast source and receiver:
  • Scenario 1: The multicast source is on the overlay network and is connected to the VXLAN through the M-LAG. The multicast receiver is on the external network.
  • Scenario 2: The multicast receiver is on the overlay network and is connected to the VXLAN through the M-LAG. The multicast source is on the external network.
  • Scenario 3: Both the multicast source and receiver are on the overlay network and are connected to the VXLAN through the M-LAG.

Scenario 1: The multicast source is on the overlay network and is connected to the VXLAN through the M-LAG. The multicast receiver is on the external network.

As shown in Figure 14-11, leaves 1-5 are distributed gateways on the VXLAN. Leaf 1 and leaf 2 form an M-LAG (active-active gateways) and are configured with the same virtual tunnel end point (VTEP) IP address and MAC address. The multicast source is on the overlay network and is connected to the VXLAN through the M-LAG. Receiver 1 is on the external network and needs to receive multicast data from the source.

Figure 14-11 Multicast traffic forwarding path when the multicast source is on the overlay network and is connected to the VXLAN through the M-LAG

In this case, the multicast traffic forwarding process is as follows:
  1. The multicast traffic is sent by the source to the M-LAG master or backup device in load balancing mode. The master or backup device encapsulates the received traffic into VXLAN traffic. The Layer 3 multicast supported by the current device in the distributed gateway scenario requires the VTEP to encapsulate multicast traffic into BUM multicast replication traffic (outer encapsulation destination IP address: address of the underlay multicast group).
  2. Encapsulated packets are transmitted on the underlay network based on underlay multicast forwarding entries. All receiver VETPs in the same L3VPN instance can receive the traffic, for example, leaf 4 and leaf 3 in Figure 14-11 can receive the traffic.
  3. After the traffic reaches the receiver VTEP, the VTEP decapsulates VXLAN traffic. Take leaf 4 as an example. After decapsulation, the multicast traffic is forwarded to receiver 1 based on the multicast forwarding entry of the external PIM network. Note that if active-active gateways are deployed for the receiver VTEP, both the master and backup gateways can receive multicast traffic from the VXLAN tunnel side. In this case, only the M-LAG master device decapsulates the multicast traffic and forwards it to the receiver. The M-LAG backup device directly discards the received multicast traffic.
NOTE:

When the multicast source accesses the M-LAG at Layer 2, there may be two access modes: active-active access and single-homing access. In either mode, you need to configure the interfaces connecting to the multicast source as M-LAG member interfaces.

Scenario 2: The multicast receiver is on the overlay network and is connected to the VXLAN through the M-LAG. The multicast source is on the external network.

As shown in Figure 14-12, leaves 1-5 are distributed gateways on the VXLAN. Leaf 1 and leaf 2 form an M-LAG (active-active gateways) and are configured with the same virtual tunnel end point (VTEP) IP address and MAC address. Receiver 1 is on the overlay network and is connected to the VXLAN through the M-LAG. The multicast source is on the external network. Receiver 1 needs to receive multicast data from the source.

Figure 14-12 Multicast traffic forwarding path when the multicast receiver is on the overlay network and is connected to the VXLAN through the M-LAG

In this case, the multicast traffic forwarding process is as follows:
  1. The multicast traffic of the source is transmitted through the external PIM network to the source VTEP leaf 4 on the VXLAN. Leaf 4 encapsulates the received traffic into VXLAN traffic. The Layer 3 multicast supported by the current device in the distributed gateway scenario requires the VTEP to encapsulate multicast traffic into BUM multicast replication traffic (outer encapsulation destination IP address: address of the underlay multicast group).
  2. Encapsulated packets are transmitted on the underlay network based on underlay multicast forwarding entries. All receiver VETPs in the same L3VPN instance can receive the traffic, for example, leaf 1, leaf 2, and leaf 3 in Figure 14-12 can receive the traffic.
  3. After the traffic reaches the receiver VTEP, the VTEP decapsulates the VXLAN traffic and forwards the traffic to receivers. For leaf 1 and leaf 2 (active-active gateways), only leaf 2 (M-LAG master device) decapsulates the multicast traffic and forwards the traffic to receivers. Leaf 1 (M-LAG backup device) discards the received multicast traffic.

When the multicast source is on the external network, the multicast source traffic may be dual-homed to the VXLAN gateway through the external network. As shown in Figure 14-13, the multicast source traffic is dual-homed to leaf 4 and leaf 5 (VXLAN gateways). In this case, both leaf 4 and leaf 5 may receive traffic from the source. As a result, the receivers receive duplicated traffic.

Figure 14-13 Multicast traffic forwarding path when the multicast source is on the external network and is dual-homed to the VXLAN (receivers receiving duplicated traffic)

To prevent receivers from receiving duplicated traffic, deploy leaf 4 and leaf 5 as an M-LAG (active-active gateways), as shown in Figure 14-14. In this case, both leaf 4 and leaf 5 can receive traffic from the multicast source, but only one leaf encapsulates the received traffic into VXLAN packets. The other leaf discards the received multicast traffic. Note that a direct Layer 3 link (multicast traffic link as shown in Figure 14-14) needs to be deployed between the active-active gateways on the source side. When the upstream link is faulty and the dual-homing access of the multicast source becomes single-homing, the Layer 3 link can be used to forward multicast traffic.

NOTE:

When an M-LAG member device needs to transmit multicast services of multiple VPN instances, you can bind each Layer 3 sub-interface to a VPN instance on the device. In this scenario, it is recommended that a Layer 3 link is established between the multicast source-side active-active gateways that form an M-LAG through Layer 3 sub-interfaces.

Figure 14-14 Multicast traffic forwarding path when the multicast source is on the external network and is connected to the VXLAN through the M-LAG

Scenario 3: Both the multicast source and receiver are on the overlay network and are connected to the VXLAN through the M-LAG.

Both the multicast source and receiver are on the overlay network. When they are connected to the VXLAN through the M-LAG, multicast traffic is processed by the source VTEP and receiver VTEP in the same way as in scenario 1 and scenario 2.

This preceding describes multicast traffic forwarding processes in different scenarios. When a link fault or device fault occurs on the network, multicast traffic switchover on links depends on convergence of unicast routes, which is the same as that in common scenarios.

Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100039595

Views: 47237

Downloads: 85

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