- play_arrow Overview
- play_arrow Managing Group Membership
- play_arrow Configuring IGMP and MLD
- play_arrow Configuring IGMP Snooping
- IGMP Snooping Overview
- Overview of Multicast Forwarding with IGMP Snooping or MLD Snooping in an EVPN-VXLAN Environment
- Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on Switches
- Example: Configuring IGMP Snooping on EX Series Switches
- Verifying IGMP Snooping on EX Series Switches
- Changing the IGMP Snooping Group Timeout Value on Switches
- Monitoring IGMP Snooping
- Example: Configuring IGMP Snooping
- Example: Configuring IGMP Snooping on SRX Series Devices
- Configuring Point-to-Multipoint LSP with IGMP Snooping
- play_arrow Configuring MLD Snooping
- Understanding MLD Snooping
- Configuring MLD Snooping on an EX Series Switch VLAN (CLI Procedure)
- Configuring MLD Snooping on a Switch VLAN with ELS Support (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on SRX Series Devices
- Configuring MLD Snooping Tracing Operations on EX Series Switches (CLI Procedure)
- Configuring MLD Snooping Tracing Operations on EX Series Switch VLANs (CLI Procedure)
- Example: Configuring MLD Snooping on EX Series Switches
- Example: Configuring MLD Snooping on Switches with ELS Support
- Verifying MLD Snooping on EX Series Switches (CLI Procedure)
- Verifying MLD Snooping on Switches
- play_arrow Configuring Multicast VLAN Registration
-
- play_arrow Configuring Protocol Independent Multicast
- play_arrow Understanding PIM
- play_arrow Configuring PIM Basics
- Configuring Different PIM Modes
- Configuring Multiple Instances of PIM
- Changing the PIM Version
- Optimizing the Number of Multicast Flows on QFabric Systems
- Modifying the PIM Hello Interval
- Preserving Multicast Performance by Disabling Response to the ping Utility
- Configuring PIM Trace Options
- Configuring BFD for PIM
- Configuring BFD Authentication for PIM
- play_arrow Routing Content to Densely Clustered Receivers with PIM Dense Mode
- play_arrow Routing Content to Larger, Sparser Groups with PIM Sparse Mode
- Understanding PIM Sparse Mode
- Examples: Configuring PIM Sparse Mode
- Configuring Static RP
- Example: Configuring Anycast RP
- Configuring PIM Bootstrap Router
- Understanding PIM Auto-RP
- Configuring All PIM Anycast Non-RP Routers
- Configuring a PIM Anycast RP Router with MSDP
- Configuring Embedded RP
- Configuring PIM Filtering
- Examples: Configuring PIM RPT and SPT Cutover
- Disabling PIM
- play_arrow Configuring Designated Routers
- play_arrow Receiving Content Directly from the Source with SSM
- Understanding PIM Source-Specific Mode
- Example: Configuring Source-Specific Multicast
- Example: Configuring PIM SSM on a Network
- Example: Configuring an SSM-Only Domain
- Example: Configuring SSM Mapping
- Example: Configuring Source-Specific Multicast Groups with Any-Source Override
- Example: Configuring SSM Maps for Different Groups to Different Sources
- play_arrow Minimizing Routing State Information with Bidirectional PIM
- play_arrow Rapidly Detecting Communication Failures with PIM and the BFD Protocol
- play_arrow Configuring PIM Options
- play_arrow Verifying PIM Configurations
-
- play_arrow Configuring Multicast Routing Protocols
- play_arrow Connecting Routing Domains Using MSDP
- play_arrow Handling Session Announcements with SAP and SDP
- play_arrow Facilitating Multicast Delivery Across Unicast-Only Networks with AMT
- play_arrow Routing Content to Densely Clustered Receivers with DVMRP
-
- play_arrow General Multicast Options
- play_arrow Bit Index Explicit Replication (BIER)
- play_arrow Prevent Routing Loops with Reverse Path Forwarding
- play_arrow Use Multicast-Only Fast Reroute (MoFRR) to Minimize Packet Loss During Link Failures
- play_arrow Enable Multicast Between Layer 2 and Layer 3 Devices Using Snooping
- play_arrow Configure Multicast Routing Options
- play_arrow Controller-Based BGP Multicast Signaling
-
- play_arrow Troubleshooting
- play_arrow Knowledge Base
-
- play_arrow Configuration Statements and Operational Commands
ON THIS PAGE
Understanding Next-Generation MVPN Control Plane
The BGP next-generation multicast virtual private network (MVPN) control plane, as specified in Internet draft draft-ietf-l3vpn-2547bis-mcast-10.txt and Internet draft draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt, distributes all the necessary information to enable end-to-end C-multicast routing exchange via BGP. The main tasks of the control plane (Table 1) include MVPN autodiscovery, distribution of provider tunnel information, and PE-PE C-multicast route exchange.
Control Plane Task | Description |
---|---|
MVPN autodiscovery | A provider edge (PE) router discovers the identity of the other PE routers that participate in the same MVPN. |
Distribution of provider tunnel information | A sender PE router advertises the type and identifier of the provider tunnel that it will use to transmit VPN multicast packets. |
PE-PE C-Multicast route exchange | A receiver PE router propagates C-multicast join messages (C-joins) received over its VPN interface toward the VPN multicast sources. |
BGP MCAST-VPN Address Family and Route Types
Internet draft draft-ietf-l3vpn-2547bis-mcast-bgp-08.txt introduced a BGP address family called MCAST-VPN for supporting next-generation MVPN control plane operations. The new address family is assigned the subsequent address family identifier (SAFI) of 5 by the Internet Assigned Numbers Authority (IANA).
A PE router that participates in a BGP-based next-generation MVPN network is required to send a BGP update message that contains MCAST-VPN network layer reachability information (NLRI). An MCAST-VPN NLRI contains route type, length, and variable fields. The value of each variable field depends on the route type.
Seven types of next-generation MVPN BGP routes (also referred to as routes in this topic) are specified (Table 2). The first five route types are called autodiscovery MVPN routes. This topic also refers to Type 1-5 routes as non-C-multicast MVPN routes. Type 6 and Type 7 routes are called C-multicast MVPN routes.
Usage | Type | Name | Description |
---|---|---|---|
Membership autodiscovery routes for inclusive provider tunnels | 1 | Intra autonomous system (intra-AS) I-PMSI autodiscovery route |
|
2 | Inter-AS I-PMSI AD route |
| |
Autodiscovery routes for selective provider tunnels | 3 | S-PMSI AD route |
|
4 | Leaf AD route |
| |
VPN multicast source discovery routes | 5 | Source active AD route |
|
C-Multicast routes | 6 | Shared tree join route |
|
7 | Source tree join route |
|
Intra-AS MVPN Membership Discovery (Type 1 Routes)
All next-generation MVPN PE routers create and advertise a Type 1 intra-AS autodiscovery route (Figure 1) for each MVPN to which they are connected. Table 3 describes the format of each MVPN Type 1 intra-AS autodiscovery route.

Field | Description |
---|---|
Route Distinguisher | Set to the route distinguisher configured for the VPN. |
Originating Router’s IP Address | Set to the IP address of the router originating this route. The address is typically the primary loopback address of the PE router. |
Inter-AS MVPN Membership Discovery (Type 2 Routes)
Type 2 routes are used for membership discovery between PE routers that belong to different autonomous systems (ASs). Their use is not covered in this topic.
Selective Provider Tunnels (Type 3 and Type 4 Routes)
A sender PE router that initiates a selective provider tunnel is required to originate a Type 3 intra-AS S-PMSI autodiscovery route with the appropriate PMSI attribute.
A receiver PE router responds to a Type 3 route by originating a Type 4 leaf autodiscovery route if it has local receivers interested in the traffic transmitted on the selective provider tunnel. Type 4 routes inform the sender PE router of the leaf PE routers.
Source Active Autodiscovery Routes (Type 5 Routes)
Type 5 routes carry information about active VPN sources and the groups to which they are transmitting data. These routes can be generated by any PE router that becomes aware of an active source. Type 5 routes apply only for PIM-SM (ASM) when intersite source-tree-only mode is being used.
C-Multicast Route Exchange (Type 6 and Type 7 Routes)
The C-multicast route exchange between PE routers refers to the propagation of C-joins from receiver PE routers to the sender PE routers.
In a next-generation MVPN, C-joins are translated into (or encoded as) BGP C-multicast MVPN routes and advertised via the BGP MCAST-VPN address family toward the sender PE routers.
Two types of C-multicast MVPN routes are specified:
Type 6 C-multicast routes are used in representing information contained in a shared tree (C-*, C-G) join.
Type 7 C-multicast routes are used in representing information contained in a source tree (C-S, C-G) join.
PMSI Attribute
The provider multicast service interface (PMSI) attribute (Figure 2) carries information about the provider tunnel. In a next-generation MVPN network, the sender PE router sets up the provider tunnel, and therefore is responsible for originating the PMSI attribute. The PMSI attribute can be attached to Type 1, Type 2, or Type 3 routes. Table 4 describes each PMSI attribute format.

Field | Description |
---|---|
Flags | Currently has only one flag specified: Leaf Information Required. This flag is used for S-PMSI provider tunnel setup. |
Tunnel Type | Identifies the tunnel technology used by the sender. Currently there are seven types of tunnels supported. |
MPLS Label | Used when the sender PE router allocates the MPLS labels (also called upstream label allocation). This technique is described in RFC 5331 and is outside the scope of this topic. |
Tunnel Identifier | Uniquely identifies the tunnel. Its value depends on the value set in the tunnel type field. |
For example, Router PE1 originates the following PMSI attribute:
PMSI: Flags 0:RSVP-TE:label[0:0:0]:Session_13[10.1.1.1:0:6574:10.1.1.1]
VRF Route Import and Source AS Extended Communities
Two extended communities are specified to support next-generation MVPNs: source AS (src-as
) and VRF route import extended communities.
The source AS extended community is an AS-specific extended community that identifies the AS from which a route originates. This community is mostly used for inter-AS operations, which is not covered in this topic.
The VPN routing and forwarding (VRF) route import extended community is an IP-address-specific extended community that is used for importing C-multicast routes in the VRF table of the active sender PE router to which the source is attached.
Each PE router creates a unique route target import and src-as community for each VPN and attaches them to the VPN-IPv4 routes.
Converting MVPN Type 5 Routes to MSDP SA
You can convert next-generation multicast virtual private network (MVPN) Type 5 routes to Multicast Source Discovery Protocol (MSDP) source active (SA) routes. This conversion helps in reducing the number of MSDP sessions running between VPN customer rendezvous points (C-RPs). For example, instead of having MSDP running among all C-RPs in a deployment, the C-RPs could instead run their MSDP sessions on a single PE router configured for multiple MSDP peers. The PE router, acting as a C-RP device, receives MVPN SA Type 5 routes from the RP-PE or the source PE router, converts those routes to MSDP, and advertises the MSDP routes to its MSDP peers.
MVPN Type 5 SA routes are added to the MVPN table. These MVPN Type 5 SA routes also include a new Extended Community (EC) with the IPv4 address of the RP where the MVPN SA was generated. The Type 5 route's source and EC are additionally added to the MSDP table. Stale routes, including the EC, are removed from the MSDP table after the MVPN Type 5 SA route is cleared from the MVPN table.
Conversion of MVPN Type 5 routes to MSDP SA is defined in RFC 9081. Previously, Junos OS only supported conversion from MSDP SA routes to MVPN Type 5.
MVPN Type 5 routes to MSDP SA conversion works in spt-only
mode.
rpt-spt
mode is not supported.
The Extended Community is IPv4 only. IPv6 is not supported, as MSDP is IPv4 only.
- Benefits of converting MVPN Type 5 routes to MSDP SA
- Enabling the conversion of MVPN Type 5 routes to MSDP SA
- Verifying the conversion of MVPN Type 5 routes to MSDP SA
Benefits of converting MVPN Type 5 routes to MSDP SA
- For MVPN provider networks, conversion of MVPN Type 5 routes to MSDP SA eliminates the need for VPN-specific MSDP sessions required among the Provider Edge (PE) routers that are customer MSDP peers.
Enabling the conversion of MVPN Type 5 routes to MSDP SA
To enable the conversion of Type 5 routes to MSDP SA, use the set
convert-sa-to-msdp
configuration statement at the hierarchy level
shown below:
[edit routing-instance instance-name protocols mvpn mvpn-mode spt-only] user@router# set convert-sa-to-msdp
Verifying the conversion of MVPN Type 5 routes to MSDP SA
Purpose
Verify that the MSDP table contains source active MVPN Type 5 routes.
Action
From operational mode, run the following show commands:
show route table instance-name.mvpn.0 extensive
—View and establish the MVPN Type 5 route.show route table instance-name.inet.4
—View the SA route converted from the MVPN Type 5 route.show msdp source-active
—Verify that the MVPN Type 5 route is populated in the MSDP table.show msdp source-active instance instance-name
—Verify that the MVPN Type 5 route is populated in the specific instance of the MSDP table.
user@host> show route table VPN-A.mvpn.0 extensive
5:192.168.1.1:1:32:10.0.0.2:32:233.252.0.1/240 (1 entry, 1 announced)
*PIM Preference: 105
Next hop type: Multicast (IPv4) Composite, Next hop index: 0
Address: 0xa3d7c24
Next-hop reference count: 3
State: <Active Int>
Age: 18
Validation State: unverified
Task: PIM.VPN-A
Announcement bits (3): 0-PIM.VPN-A 1-mvpn global task 2-rt-export
AS path: I
Communities: mvpn-sa-rp:192.168.0.1:0
user@host> show route table instance.inet.4
instance.inet.4: 1 destination, 1 route (1 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
233.252.0.1,10.0.0.2/64*[MSDP/175/2] 00:00:46, from 192.168.0.1
Local
user@host> show msdp source-active
Group address Source address Peer address Originator Flags
233.252.0.1 10.0.0.2 192.168.0.3 192.168.0.1 Accept
user@host> show msdp source-active instance VPN-A
Group address Source address Peer address Originator Flags
233.252.0.1 10.0.0.2 local 192.168.0.1 Accept
Meaning
The
show route table VPN-A.mvpn.0 extensive
output shows the Extended community (EC) with the IPv4 address of the RP where the MVPN SA was generated, under the Type 5 route table.The
show route table instance.inet.4
output shows the route table with the multicast group address, the source and the SA converted route.- The
show msdp source-active
output shows the MSDP table with all the source active routes received from its neighbors. In this case, 192.168.0.1 is displayed as the originator, which is the IPv4 address of the source RP received from the Type 5 route. - The
show msdp source-active instance VPN-A
output shows the MSDP table for VPN-A. In this case too, 192.168.0.1 is displayed as the originator, which is the IPv4 address of the source RP received from the Type 5 route.