Related Documentation
Example: Configuring Draft-Rosen MVPN Interoperability
Configuring Draft-Rosen Multicast VPNs
Draft-rosen multicast virtual private networks (MVPNs) can be configured to support service provider tunnels operating in any-source multicast (ASM) mode or source-specific multicast (SSM) mode.
There are three functional areas to configure for draft-rosen MVPNs with service provider tunnels operating in SSM mode:
- Provider tunnel
- Autodiscovery mechanism
- Control plane protocol
In the unicast environment for Layer 3 VPNs, all VPN state information is contained within the PE routers.
However, with multicast for Layer 3 VPNs, PIM adjacencies are established in one of the following ways:
- You can set PIM adjacencies between the customer edge (CE) router and the PE router through a VPN routing and forwarding (VRF) instance at the [edit routing-instances instance-name protocols pim] hierarchy level. You must include the vpn-group-address statement at this hierarchy level, specifying a multicast group. The RP listed in the VRF-instance is the VPN customer RP (C-RP).
- You can also set the master PIM instance and the PE's IGP neighbors by configuring statements at the [edit protocols pim] hierarchy level. You must add the multicast group specified in the VRF instance to the master PIM instance. The set of master PIM adjacencies throughout the service provider network makes up the forwarding path that becomes an RP tree rooted at the service provider RP (SP-RP). Therefore, provider (P) routers within the provider core must maintain multicast state information for the VPNs.
For this configuration to work properly, you need two types of RP routers for each VPN:
- A VPN C-RP—An RP router located somewhere within the customer VPN
- An SP-RP—An RP router located within the service
provider network
Note: A PE router can act as an SP-RP or the VPN C-RP of a VPN. However, when auto-RP and BSR are used, the PE cannot be a C-RP. It can, however, learn another router as C-RP by means of the auto-RP or BSR protocols.
Understanding MVPN Interoperation with Other Vendors
This section presents notes on interoperating with other vendors in a draft-rosen multicast VPN.
If your Juniper Networks routers must interoperate with other vendors’ routers, take one of these approaches:
- Configure the other vendors’ routers to interoperate with the Juniper Networks routers.
- Configure the Juniper Networks routers to interoperate with the other vendors’ routers.
If you are configuring the other vendors’ routers to operate like Juniper Networks routers, verify the following:
- All provider tunnels use the same group address.
- On all routers, the lo0.n interface IP address in the routing instance matches the IP address on the lo0.0 interface in the master instance.
By default the Junos OS attaches a route target to multicast distribution tree (MDT) subsequent address family identifier (SAFI) network layer reachability information (NLRI) route advertisements. Some vendors do not support attaching route targets to the MDT-SAFI route advertisements.
For interoperability with these vendors, the Junos OS allows importing of MDT-SAFI route advertisements without a route target being attached. The MDT-SAFI is imported if the MDT default address in the MDT-SAFI prefix matches the MDT default address configured within the routing instance.
Example: Configuring Draft Rosen Interoperability and a VPN Tunnel Source
This example shows how to change the behavior of draft-rosen in the Junos OS for interoperability with certain other vendors’ routing platforms.
Requirements
Before you begin:
- Configure the router interfaces. See the Junos OS Network Interfaces Library for Routing Devices.
- Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Library for Routing Devices.
- Configure the VPN. See the Junos OS VPNs Library for Routing Devices.
- Make sure that the routing devices support multicast tunnel
(mt) interfaces for encapsulating and de-encapsulating data
packets into tunnels. See Tunnel Services PICs and Multicast and Load Balancing Multicast Tunnel Interfaces Among Available PICs.
For multicast to work on draft-rosen Layer 3 VPNs, each of the following routers must have tunnel interfaces:
- Each provider edge (PE) router.
- Any provider (P) router acting as the RP.
- Any customer edge (CE) router that is acting as a source's DR or as an RP. A receiver's designated router does not need a Tunnel Services PIC.
Overview
By default, the local loopback address configured in a VPN routing and forwarding (VRF) routing instance is used as the source address when PIM hello messages, join messages, and prune messages are sent over multicast tunnel interfaces.
In the Junos OS default implementation of draft-rosen, mt interfaces are created dynamically in each VRF. PIM hello messages are sent over the mt interfaces to discover neighbors in the same VPN. The Junos OS requires that the lo0.mvpn address be configured in each routing instance. The local lo0.mvpn address is used as the source address when building PIM hello, join, and prune messages over the mt interface. The lo0.mvpn address is independent in routing instances and can be different from the lo0.main address in the master instance. All the source and destination address lookups and RPF checks are done in the routing instance.
For compatibility with certain other vendors’ routers, the address used in the VRF routing instance for multicast tunnel interfaces must be the same as the primary loopback address configured in the master routing instance. In this example, mt interfaces use lo0.0 as the source address. Each VRF routing instance uses the lo0.0 address as the source address when sending PIM control packets over the mt interface.
Before configuring the loopback address used for PIM control messages to be the primary loopback address configured in the default routing instance, ensure that:
- The loopback address specified is configured in the master routing instance.
- The inet address family is enabled on the interface.
This example also configures a specific VPN tunnel source address in one routing instance. That address, instead of the lo0.main address, is used as the source address for the mt interface in that routing instance. The tunnel source is a static local address that is routable in the master instance. The routing instance uses the VPN tunnel source to form PIM neighbors over the mt interface. This enables different routing instances to take different paths even in the provider domain.
![]() | Note: For information about upgrading Juniper Networks routers from a software release that does not support the default-vpn-source configuration statement to a release that does, see the Juniper Networks Junos 10.1 Software Release Notes . |
This example includes the following settings:
- default-vpn-source—In the master instance, changes the draft-rosen behavior so that the primary loopback address configured in the master routing instance is the multicast tunnel interface address in all VRF routing instances. Because the configuration includes default-vpn-source, you do not need to configure loopback addresses in the routing instances.
- tunnel-source—In the vrf-blue routing instance, overrides the default-vpn-source statement. The vrf-blue routing instance (because it contains the unnel-source statement) overrides the default-vpn-source statement and uses the address configured on lo0.200 as the source address. This address is 192.27.11.136 in this example. However, vrf-white does not contain the tunnel-source statement. In this case, the default-vpn-source statement takes effect, and vrf-white uses the address configured on lo0.0 as the source address. This address is 192.27.0.136 in this example.
Figure 1 shows the topology used in this example.
Figure 1: VPN Tunnel Source Topology

This example shows the Junos OS configuration on Device PE2.
Configuration
CLI Quick Configuration
To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.
Device PE2
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode in the CLI User Guide.
To change the default draft-rosen behavior and configure a VPN tunnel source in a routing instance:
On the PE routers, configure the interfaces.
[edi interfacest]user@PE2# set fe-4/3/0 description "TO CE2"user@PE2# set fe-4/3/0 unit 0 family inet address 1.2.3.1/24user@PE2# set fe-4/3/0 unit 0 family isouser@PE2# set fe-4/3/0 unit 0 family mpls
user@PE2# set so-2/3/0 description "TO PE1"user@PE2# set so-2/3/0 sonet-options fcs 32user@PE2# set so-2/3/0 sonet-options no-payload-scrambleruser@PE2# set so-2/3/0 unit 0 family inet address 1.1.2.2/24user@PE2# set so-2/3/0 unit 0 family isouser@PE2# set so-2/3/0 unit 0 family mpls
user@PE2# set lo0 unit 1 family inet address 10.255.70.103/32Configure the MPLS and a signaling protocol.
[edit protocols mpls]user@PE2# set interface alluser@PE2# set interface fxp0.0 disable
[edit protocols ldp]user@PE2# set interface alluser@PE2# set interface fxp0.0 disableConfigure the routing protocols in the master instance.
[edit protocols bgp group int]user@PE2# set type internaluser@PE2# set local-address 10.255.70.103user@PE2# set family inet unicastuser@PE2# set family inet-vpn unicastuser@PE2# set family inet-vpn multicastuser@PE2# set family inet-mdt signalinguser@PE2# set neighbor 10.10.10.10
[edit protocols ospf area 0.0.0.0]user@PE2# set interface alluser@PE2# set interface fxp0.0 disableConfigure PIM with the default-vpn-source statement.
[edit protocols pim]user@PE2# set interface lo0.0user@PE2# set interface alluser@PE2# set interface fxp0.0 disableuser@PE2# set default-vpn-sourceConfigure the routing policy.
[edit policy-options policy-statement bgp_ospf term 1]user@PE2# set from protocol bgpuser@PE2# set then acceptConfigure the routing instance.
[edit routing-instances vpna]user@PE2# set instance-type vrfuser@PE2# set interface fe-4/3/0.0user@PE2# set interface lo0.1user@PE2# set route-distinguisher 1:0user@PE2# set provider-tunnel pim-ssm group-address 232.1.1.1user@PE2# set vrf-target target:1:1user@PE2# set protocols ospf export bgp_ospfuser@PE2# set protocols ospf area 0.0.0.0 interface lo0.1 passiveuser@PE2# set protocols ospf area 0.0.0.0 interface fe-4/3/0.0user@PE2# set protocols pim mvpn autodiscovery inet-mdtuser@PE2# set protocols pim rp local address 10.255.70.103user@PE2# set protocols pim interface lo0.1user@PE2# set protocols pim interface fe-4/3/0.0user@PE2# set protocols mvpn autodiscovery-only intra-as inclusiveConfigure the routing table options.
[edit routing-options]user@PE2# set autonomous-system 1If you are done configuring the device, commit the configuration.
user@PE2# commit
Results
From configuration mode, confirm your configuration by entering the show interfaces, show policy-options, show protocols, show routing-instances, and show routing-options commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.
Verification
To verify the configuration, run the show pim mdt instance vpna should show the data MDT and the VPN tunnel source. Other useful commands are show pim join (main instance), show multicast route, and show pim neighbors.