In the following example we will show how to configure Multicast Draft Rosen 6, which basically sends Any Source Multicast traffic over L3VPN.

This document assumes you have basic understanding of the following technologies: OSPF, MPLS, LDP, BGP, L3VPN, PIM and IGMP. 

We are going to use the following topology for this example.

The following topology has the following configuration already in place:

OSPF in the core-facing interfaces and PE loopbacks

Once we confirm that the unicast path is working as expected we can focus on our Draft Rosen 6 configuration.

NOTE = In this kind of set up there are two PIM domains running, one PIM domain is running between the PEs, another PIM domain is running between L3VPNs.

Start by configuring the following:

-PIM in the CE facing interfaces as well as the loopbacks.

-MVPN under protocols PIM

-Static RP address - this is the RP address for the MVPN PIM domain.

root@PE1_re0# run show configuration routing-instances VPN-A protocols    
pim {
    mvpn;
    rp {
        static {
            address 3.3.3.3;
        }
    }
    interface lo0.1;
    interface ge-0/0/0.0;
}

After this configure a provider tunnel under all L3VPN participating instances, this will create the tunnel which allows C-PIM multicast traffic to be shared from the Source to the Revivers.

root@PE1_re0> show configuration routing-instances VPN-A 
provider-tunnel {
    pim-asm {
        group-address 239.2.2.2;
    }
}

You can use the below command to confirm if the group was properly created, you can also confirm the mt outgoing/incoming interfaces.

Note - the interfaces mt are automatically created.

root@PE1_re0> show pim mdt instance VPN-A 
Instance: PIM.VPN-A Family: INET

Tunnel direction: Outgoing
Tunnel mode: PIM-SM
Default group address: 239.2.2.2      
Default source address: 0.0.0.0        
Default tunnel interface: mt-0/0/0.32768 
Default tunnel source: 0.0.0.0        

Tunnel direction: Incoming
Tunnel mode: PIM-SM
Default group address: 239.2.2.2      
Default source address: 0.0.0.0        
Default tunnel interface: mt-0/0/0.1081344 
Default tunnel source: 0.0.0.0 

You can use the below command to verify your C-PIM neighbors 

root@PE1_re0> show pim neighbors instance VPN-A 
B = Bidirectional Capable, G = Generation Identifier
H = Hello Option Holdtime, L = Hello Option LAN Prune Delay,
P = Hello Option DR Priority, T = Tracking Bit,
A = Hello Option Join Attribute

Instance: PIM.VPN-A
Interface           IP V Mode        Option       Uptime Neighbor addr
mt-0/0/0.32768       4 2             HPLGTA      00:20:10 2.2.2.2        
mt-0/0/0.32768       4 2             HPLGTA      00:20:10 3.3.3.3

-----------------------------------------------------------------------------------------------------------------------------------------

Now it looks like everything is up now we need to test if the Multicast traffic can communicate between Source and Receivers but how can we do this?

Juniper routers are not like other vendors, they do not send IGMP Membership Reports by default, they need a "special kind of configuration".

Think about a push and pull mechanism, let's say other vendors push "IGMP Membership Reports", Juniper needs something to pull them.

To make this possible we need to go to the Receivers and configure the following.

Receiver2 configuration example

set protocols igmp interface ge-0/0/0.0 static group 239.1.1.2 --------> this command will help us to generate "IGMP Membership Reports" when the source pull them.
set protocols sap listen 239.1.1.2 --------> this command will help us to listen traffic for the desired group.
set protocols pim rp static address 3.3.3.3 --------> this command specified the C-PIM RP address. 
set protocols pim interface ge-0/0/0.0 --------> this command works together with "protocols igmp interface", without it "protocols igmp interface" will not work.

-----------------------------------------------------------------------------------------------------------------------------------------

Once the above has been completed the Receivers are ready listening traffic, waiting for something to pull the traffic from them.

This is where the Source comes into play, the Source will be the device that will help us to pull the information from the Receives.

In the source we usually configure a default static route that help us to push the unknow traffic towards PE1.

set routing-options static route 0.0.0.0/0 next-hop 192.168.200.1

root@Source_re0> show route 239.1.1.2 

inet.0: 12 destinations, 12 routes (12 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both

0.0.0.0/0          *[Static/5] 23:26:52
                    >  to 192.168.200.1 via ge-0/0/0.0

-----------------------------------------------------------------------------------------------------------------------------------------

We start a ping from the Source using bypass-routing knob and a TTL increased to pull multicast traffic from the Receivers 

root@Source_re0> ping 239.1.1.2 bypass-routing interface ge-0/0/0.0 ttl 200    
PING 239.1.1.2 (239.1.1.2): 56 data bytes
64 bytes from 192.168.220.2: icmp_seq=0 ttl=61 time=6.476 ms
64 bytes from 192.168.220.2: icmp_seq=1 ttl=61 time=7.231 ms
64 bytes from 192.168.220.2: icmp_seq=2 ttl=61 time=6.511 ms
64 bytes from 192.168.220.2: icmp_seq=3 ttl=61 time=6.307 ms

Below a capture on the Source interface, we can see multicast traffic getting out and coming back.

root@Source_re0> monitor traffic interface ge-0/0/0 no-resolve matching icmp 
verbose output suppressed, use <detail> or <extensive> for full protocol decode
Address resolution is OFF.
Listening on ge-0/0/0, capture size 96 bytes

17:28:51.778374 Out IP truncated-ip - 24 bytes missing! 192.168.200.2 > 239.1.1.2: ICMP echo request, id 15419, seq 0, length 64
17:28:51.784751  In IP 192.168.220.2 > 192.168.200.2: ICMP echo reply, id 15419, seq 0, length 64
17:28:52.779502 Out IP truncated-ip - 24 bytes missing! 192.168.200.2 > 239.1.1.2: ICMP echo request, id 15419, seq 1, length 64
17:28:52.786624  In IP 192.168.220.2 > 192.168.200.2: ICMP echo reply, id 15419, seq 1, length 64
17:28:53.785971 Out IP truncated-ip - 24 bytes missing! 192.168.200.2 > 239.1.1.2: ICMP echo request, id 15419, seq 2, length 64
17:28:53.792411  In IP 192.168.220.2 > 192.168.200.2: ICMP echo reply, id 15419, seq 2, length 64
17:28:54.792931 Out IP truncated-ip - 24 bytes missing! 192.168.200.2 > 239.1.1.2: ICMP echo request, id 15419, seq 3, length 64
17:28:54.799151  In IP 192.168.220.2 > 192.168.200.2: ICMP echo reply, id 15419, seq 3, length 64

-----------------------------------------------------------------------------------------------------------------------------------------

We can verify many things, below we can see that the Receiver 2 join the Share Path Tree/(*,G) and Shortest Path Tree/(S,G).

root@Receiver2_re0> show pim join 239.1.1.2 
Instance: PIM.master Family: INET
R = Rendezvous Point Tree, S = Sparse, W = Wildcard

Group: 239.1.1.2
    Source: *
    RP: 3.3.3.3
    Flags: sparse,rptree,wildcard
    Upstream interface: ge-0/0/0.0            

Group: 239.1.1.2
    Source: 192.168.200.2
    Flags: sparse,spt
    Upstream interface: ge-0/0/0.0  

-----------------------------------------------------------------------------------------------------------------------------------------

With the above test we confirm that Multicast traffic is passing through the L3VPN.

7/15/2025 dconejomora - creating KB