Rate and give feedback:  Feedback Received. Thank You!

Rate and give feedback: 

X

This document helped resolve my issue

Yes No

Additional Comments

800 characters remaining

May we contact you if necessary?

Name:  

E-mail: 

Enter a valid Email ID

Need product assistance? Contact Juniper Support

Submit

This site is protected by hCaptcha and its Privacy Policy and Terms of Service apply.

English  

English

Examples: Configuring PIM Sparse Mode

Understanding PIM Sparse Mode

A Protocol Independent Multicast (PIM) sparse-mode domain uses reverse-path forwarding (RPF) to create a path from a data source to the receiver requesting the data. When a receiver issues an explicit join request, an RPF check is triggered. A (*,G) PIM join message is sent toward the RP from the receiver's designated router (DR). (By definition, this message is actually called a join/prune message, but for clarity in this description, it is called either join or prune, depending on its context.) The join message is multicast hop by hop upstream to the ALL-PIM-ROUTERS group (224.0.0.13) by means of each router’s RPF interface until it reaches the RP. The RP router receives the (*,G) PIM join message and adds the interface on which it was received to the outgoing interface list (OIL) of the rendezvous-point tree (RPT) forwarding state entry. This builds the RPT connecting the receiver with the RP. The RPT remains in effect, even if no active sources generate traffic.

Note: State—the (*,G) or (S,G) entries—is the information used for forwarding unicast or multicast packets. S is the source IP address, G is the multicast group address, and * represents any source sending to group G. Routers keep track of the multicast forwarding state for the incoming and outgoing interfaces for each group.

When a source becomes active, the source DR encapsulates multicast data packets into a PIM register message and sends them by means of unicast to the RP router.

If the RP router has interested receivers in the PIM sparse-mode domain, it sends a PIM join message toward the source to build a shortest-path tree (SPT) back to the source. The source sends multicast packets out on the LAN, and the source DR encapsulates the packets in a PIM register message and forwards the message toward the RP router by means of unicast. The RP router receives PIM register messages back from the source, and thus adds a new source to the distribution tree, keeping track of sources in a PIM table. Once an RP router receives packets natively (with S,G), it sends a register stop message to stop receiving the register messages by means of unicast.

In actual application, many receivers with multiple SPTs are involved in a multicast traffic flow. To illustrate the process, we track the multicast traffic from the RP router to one receiver. In such a case, the RP router begins sending multicast packets down the RPT toward the receiver’s DR for delivery to the interested receivers. When the receiver’s DR receives the first packet from the RPT, the DR sends a PIM join message toward the source DR to start building an SPT back to the source. When the source DR receives the PIM join message from the receiver’s DR, it starts sending traffic down all SPTs. When the first multicast packet is received by the receiver’s DR, the receiver’s DR sends a PIM prune message to the RP router to stop duplicate packets from being sent through the RPT. In turn, the RP router stops sending multicast packets to the receiver’s DR, and sends a PIM prune message for this source over the RPT toward the source DR to halt multicast packet delivery to the RP router from that particular source.

If the RP router receives a PIM register message from an active source but has no interested receivers in the PIM sparse-mode domain, it still adds the active source into the PIM table. However, after adding the active source into the PIM table, the RP router sends a register stop message. The RP router discovers the active source’s existence and no longer needs to receive advertisement of the source (which utilizes resources).

Note: If the number of PIM join messages exceeds the configured MTU, the messages are fragmented in IPv6 PIM sparse mode. To avoid the fragmentation of PIM join messages, the multicast traffic receives the interface MTU instead of the path MTU.

The major characteristics of PIM sparse mode are as follows:

• Routers with downstream receivers join a PIM sparse-mode tree through an explicit join message.
• PIM sparse-mode RPs are the routers where receivers meet sources.
• Senders announce their existence to one or more RPs, and receivers query RPs to find multicast sessions.
• Once receivers get content from sources through the RP, the last-hop router (the router closest to the receiver) can optionally remove the RP from the shared distribution tree (*,G) if the new source-based tree (S,G) is shorter. Receivers can then get content directly from the source.

  The transitional aspect of PIM sparse mode from shared to source-based tree is one of the major features of PIM, because it prevents overloading the RP or surrounding core links.

• Sources must be able to send to all RPs.
• RPs must all know one another.
• Receivers must send explicit join messages to a known RP.
• Receivers initially need to know only one RP (they later learn about others).
• Receivers can explicitly prune themselves from a tree.
• Receivers that never transition to a source-based tree are effectively running Core Based Trees (CBT)`.

PIM sparse mode has standard features for all of these issues.

Rendezvous Point

The RP router serves as the information exchange point for the other routers. All routers in a PIM domain must provide mapping to an RP router. It is the only router that needs to know the active sources for a domain—the other routers just need to know how to reach the RP. In this way, the RP matches receivers with sources.

The RP router is downstream from the source and forms one end of the shortest-path tree. As shown in Figure 1, the RP router is upstream from the receiver and thus forms one end of the rendezvous-point tree.

Figure 1: Rendezvous Point as Part of the RPT and SPT

The benefit of using the RP as the information exchange point is that it reduces the amount of state in non-RP routers. No network flooding is required to provide non-RP routers information about active sources.

RP Mapping Options

• Static configuration
• Anycast RP
• Auto-RP
• Bootstrap router

We recommend a static RP mapping with anycast RP and a bootstrap router (BSR) with auto-RP configuration, because static mapping provides all the benefits of a bootstrap router and auto-RP without the complexity of the full BSR and auto-RP mechanisms.

Designated Router

In a PIM sparse mode (PIM-SM) domain, there are two types of designated routers to consider:

• The receiver DR sends PIM join and PIM prune messages from the receiver network toward the RP.
• The source DR sends PIM register messages from the source network to the RP.

Neighboring PIM routers multicast periodic PIM hello messages to each other every 30 seconds (the default). The PIM hello message usually includes a holdtime value for the neighbor to use, but this is not a requirement. If the PIM hello message does not include a holdtime value, a default timeout value (in Junos OS, 105 seconds) is used. On receipt of a PIM hello message, a router stores the IP address and priority for that neighbor. If the DR priorities match, the router with the highest IP address is selected as the DR.

If a DR fails, a new one is selected using the same process of comparing IP addresses.

Note: In PIM dense mode (PIM-DM), a DR is elected by the same process that PIM-SM uses. However, the only time that a DR has any effect in PIM-DM is when IGMPv1 is used on the interface. (IGMPv2 is the default.) In this case, the DR also functions as the IGMP Query Router because IGMPv1 does not have a Query Router election mechanism.

Tunnel Services PICs and Multicast

On Juniper Networks routers, data packets are encapsulated and de-encapsulated into tunnels by means of hardware and not the software running on the router processor. The hardware used to create tunnel interfaces on M Series and T Series routers is a Tunnel Services PIC. If Juniper Networks M Series Multiservice Edge Routers and Juniper Networks T Series Core Routers are configured as rendezvous points or IP version 4 (IPv4) PIM sparse-mode DRs connected to a source, a Tunnel Services PIC is required. Juniper Networks MX Series Ethernet Services Routers do not require Tunnel Services PICs. However, on MX Series routers, you must enable tunnel services with the tunnel-services statement on one or more online FPC and PIC combinations at the [edit chassis fpc number pic number] hierarchy level.

Caution: For redundancy, we strongly recommend that each routing device has multiple Tunnel Services PICs. In the case of MX Series routers, the recommendation is to configure multiple tunnel-services statements. We also recommend that the Tunnel PICs be installed (or configured) on different FPCs. If you have only one Tunnel PIC or if you have multiple Tunnel PICs installed on a single FPC and then that FPC is removed, the multicast session will not come up. Having redundant Tunnel PICs on separate FPCs can help ensure that at least one Tunnel PIC is availble and that multicast will continue working. On MX Series routers, the redundant configuration looks like the following example: [edit chassis]user@mx-host# set fpc 1 pic 0 tunnel-services bandwidth 1g user@mx-host# set fpc 2 pic 0 tunnel-services bandwidth 1g

In PIM sparse mode, the source DR takes the initial multicast packets and encapsulates them in PIM register messages. The source DR then unicasts the packets to the PIM sparse-mode RP router, where the PIM register message is de-encapsulated.

When a router is configured as a PIM sparse-mode RP router (by specifying an address using the address statement at the [edit protocols pim rp local] hierarchy level) and a Tunnel PIC is present on the router, a PIM register de-encapsulation interface, or pd interface, is automatically created. The pd interface receives PIM register messages and de-encapsulates them by means of the hardware.

If PIM sparse mode is enabled and a Tunnel Services PIC is present on the router, a PIM register encapsulation interface (pe interface) is automatically created for each RP address. The pe interface is used to encapsulate source data packets and send the packets to RP addresses on the PIM DR and the PIM RP. The pe interface receives PIM register messages and encapsulates the packets by means of the hardware.

Do not confuse the configurable pe and pd hardware interfaces with the nonconfigurable pime and pimd software interfaces. Both pairs encapsulate and de-encapsulate multicast packets, and are created automatically. However, the pe and pd interfaces appear only if a Tunnel Services PIC is present. The pime and pimd interfaces are not useful in situations requiring the pe and pd interfaces.

If the source DR is the RP, then there is no need for PIM register messages and consequently no need for a Tunnel Services PIC.

When PIM sparse mode is used with IP version 6 (IPv6), a Tunnel PIC is required on the RP, but not on the IPv6 PIM DR. The lack of a Tunnel PIC requirement on the IPv6 DR applies only to IPv6 PIM sparse mode and is not to be confused with IPv4 PIM sparse-mode requirements.

Table 1 shows the complete matrix of IPv4 and IPv6 PIM Tunnel PIC requirements.

Enabling PIM Sparse Mode

In PIM sparse mode (PIM-SM), the assumption is that very few of the possible receivers want packets from a source, so the network establishes and sends packets only on branches that have at least one leaf indicating (by message) a desire for the traffic. WANs are appropriate networks for sparse-mode operation.

By default, PIM is disabled. When you enable PIM, it operates in sparse mode by default. You do not need to configure Internet Group Management Protocol (IGMP) version 2 for a sparse mode configuration. After you enable PIM, by default, IGMP version 2 is also enabled.

1. Configure the static RP router.
   [edit protocols pim]user@host# set rp local family inet address 192.168.3.253
2. Configure the RP router interfaces. When configuring all interfaces, exclude the fxp0.0 management interface by including the disable statement for that interface.
   [edit protocols pim]user@host# set interface all mode sparseuser@host# set interface all version 2user@host# set interface fxp0.0 disable
3. Configure the non-RP routers. Include the following configuration on all of the non-RP routers.
   [edit protocols pim]user@host# set rp static address 198.58.3.253 version 2user@host# set interface all mode sparseuser@host# set interface all version 2user@host# set interface fxp0.0 disable
4. Monitor the operation of PIM sparse mode.
   • show pim interfaces
   • show pim join
   • show pim neighbors
   • show pim rps

Configuring PIM Join Load Balancing

By default, PIM join messages are sent toward a source based on the RPF routing table check. If there is more than one equal-cost path toward the source, then one upstream interface is chosen to send the join message. This interface is also used for all downstream traffic, so even though there are alternative interfaces available, the multicast load is concentrated on one upstream interface and routing device.

For PIM sparse mode, you can configure PIM join load balancing to spread join messages and traffic across equal-cost upstream paths (interfaces and routing devices) provided by unicast routing toward a source. PIM join load balancing is only supported for PIM sparse mode configurations.

PIM join load balancing is supported on draft-rosen multicast VPNs (also referred to as dual PIM multicast VPNs). PIM join load balancing is not supported on multiprotocol BGP-based multicast VPNs (also referred to as next-generation Layer 3 VPN multicast). When PIM join load balancing is enabled in a draft-rosen Layer 3 VPN scenario, the load balancing is achieved based on the join counts for the far-end PE routing devices, not for any intermediate P routing devices.

If an internal BGP (IBGP) multipath forwarding VPN route is available, the Junos OS uses the multipath forwarding VPN route to send join messages to the remote PE routers to achieve load balancing over the VPN.

By default, when multiple PIM joins are received for different groups, all joins are sent to the same upstream gateway chosen by the unicast routing protocol. Even if there are multiple equal-cost paths available, these alternative paths are not utilized to distribute multicast traffic from the source to the various groups.

When PIM join load balancing is configured, the PIM joins are distributed equally among all equal-cost upstream interfaces and neighbors. Every new join triggers the selection of the least-loaded upstream interface and neighbor. If there are multiple neighbors on the same interface (for example, on a LAN), join load balancing maintains a value for each of the neighbors and distributes multicast joins (and downstream traffic) among these as well.

Join counts for interfaces and neighbors are maintained globally, not on a per-source basis. Therefore, there is no guarantee that joins for a particular source are load-balanced. However, the joins for all sources and all groups known to the routing device are load-balanced. There is also no way to administratively give preference to one neighbor over another: all equal-cost paths are treated the same way.

You can configure message filtering globally or for a routing instance. This example shows the global configuration.

1. Determine if there are multiple paths available for a source (for example, an RP) with the output of the show pim join extensive or show pim source commands.
   user@host> show pim join extensive

   Instance: PIM.master Family: INET
   
   Group: 224.1.1.1
       Source: *
       RP: 10.255.245.6
       Flags: sparse,rptree,wildcard
       Upstream interface: t1-0/2/3.0
       Upstream neighbor: 192.168.38.57
       Upstream state: Join to RP
       Downstream neighbors:
           Interface: t1–0/2/1.0
               192.168.38.16 State: JOIN Flags; SRW Timeout: 164
   Group: 224.2.127.254
       Source: *
       RP: 10.255.245.6
       Flags: sparse,rptree,wildcard
       Upstream interface: so–0/3/0.0
       Upstream neighbor: 192.168.38.47
       Upstream state: Join to RP
       Downstream neighbors:
           Interface: t1–0/2/3.0
               192.168.38.16 State: JOIN Flags; SRW Timeout: 164

   Note that for this router, the RP at IP address 10.255.245.6 is the source for two multicast groups: 224.1.1.1 and 224.2.127.254. This router has two equal-cost paths through two different upstream interfaces (t1-0/2/3.0 and so-0/3/0.0) with two different neighbors (192.168.38.57 and 192.168.38.47). This router is a good candidate for PIM join load balancing.

2. On the non-RP router, configure PIM join load balancing.
   [edit protocols pim rp]user@host# set static address 10.10.10.1user@host# set interface all mode sparse version 2user@host# set join-load-balance

   The static address is the address of the RP.

3. Monitor the operation.

   If load balancing is enabled for this router, the number of PIM joins sent on each interface is shown in the output for the show pim interfaces command.

   user@host> show pim interfaces

   Instance: PIM.master
   
   Name             Stat Mode        IP V State NbrCnt JoinCnt   DR address
   lo0.0            Up   Sparse       4 2 DR         0       0   10.255.168.58
   pe-1/2/0.32769   Up   Sparse       4 2 P2P        0       0 
   so-0/3/0.0       Up   Sparse       4 2 P2P        1       1 
   t1-0/2/1.0       Up   Sparse       4 2 P2P        1       0 
   t1-0/2/3.0       Up   Sparse       4 2 P2P        1       1 
   lo0.0            Up   Sparse       6 2 DR         0       0   fe80::2a0:a5ff:4b7

   Note that the two equal-cost paths shown by the show pim interfaces command now have nonzero join counts. If the counts differ by more than one and were zero (0) when load balancing commenced, an error occurs (joins before load balancing are not redistributed). The join count also appears in the show pim neighbors detail output:

   user@host> show pim neighbors detail

   Interface: so-0/3/0.0
   
       Address: 192.168.38.46, IPv4, PIM v2, Mode: Sparse, Join Count: 0
           Hello Option Holdtime: 65535 seconds
           Hello Option DR Priority: 1
           Hello Option Generation ID: 1689116164
           Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
   
       Address: 192.168.38.47, IPv4, PIM v2, Join Count: 1
           BFD: Disabled
           Hello Option Holdtime: 105 seconds 102 remaining
           Hello Option DR Priority: 1
           Hello Option Generation ID: 792890329
           Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
   
   Interface: t1-0/2/3.0
   
       Address: 192.168.38.56, IPv4, PIM v2, Mode: Sparse, Join Count: 0
           Hello Option Holdtime: 65535 seconds
           Hello Option DR Priority: 1
           Hello Option Generation ID: 678582286
           Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
   
       Address: 192.168.38.57, IPv4, PIM v2, Join Count: 1
           BFD: Disabled
           Hello Option Holdtime: 105 seconds 97 remaining
           Hello Option DR Priority: 1
           Hello Option Generation ID: 1854475503
           Hello Option LAN Prune Delay: delay 500 ms override 2000 ms
   

   Note that the join count is nonzero on the two load-balanced interfaces toward the upstream neighbors.

   PIM join load balancing only takes effect when the feature is configured. Prior joins are not redistributed to achieve perfect load balancing. In addition, if an interface or neighbor fails, the new joins are redistributed among remaining active interfaces and neighbors. However, when the interface or neighbor is restored, prior joins are not redistributed. The clear pim join-distribution command redistributes the existing flows to new or restored upstream neighbors. Redistributing the existing flows causes traffic to be disrupted, so we recommend that you perform PIM join redistribution during a maintenance window.

Modifying the Join State Timeout

To modify the timeout, include the join-prune-timeout statement:

The join timeout value can be from 210 through 240 seconds.

Example: Enabling Join Suppression

This example describes how to enable PIM join suppression.

• Requirements
• Overview
• Configuration
• Verification

Requirements

Before you begin:

• Configure the router interfaces. See the Junos® OS Network Interfaces.
• Configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Configuration Guide.
• Configure PIM Sparse Mode on the interfaces. See Enabling PIM Sparse Mode.

Overview

PIM join suppression enables a router on a multiaccess network to defer sending join messages to an upstream router when it sees identical join messages on the same network. Eventually, only one router sends these join messages, and the other routers suppress identical messages. Limiting the number of join messages improves scalability and efficiency by reducing the number of messages sent to the same router.

• override-interval—Sets the maximum time in milliseconds to delay sending override join messages. When a router sees a prune message for a join it is currently suppressing, it waits before it sends an override join message. Waiting helps avoid multiple downstream routers sending override join messages at the same time. The override interval is a random timer with a value of 0 through the maximum override value.
• propagation-delay—Sets a value in milliseconds for a prune pending timer, which specifies how long to wait before executing a prune on an upstream router. During this period, the router waits for any prune override join messages that might be currently suppressed. The period for the prune pending timer is the sum of the override-interval value and the value specified for propagation-delay.
• reset-tracking-bit—Enables PIM join suppression on each multiaccess downstream interface. This statement resets a tracking bit field (T-bit) on the LAN prune delay hello option from the default of 1 (join suppression disabled) to 0 (join suppression enabled).

  When multiple identical join messages are received, a random join suppression timer is activated, with a range of 66 through 84 milliseconds. The timer is reset each time join suppression is triggered.

Figure 2 shows the topology used in this example.

Figure 2: Join Suppression

• Host 0 is the multicast source.
• Host 1, Host 2, Host 3, and Host 4 are receivers.
• Router R0 is the first-hop router and the RP.
• Router R1 is an upstream router.
• Routers R2, R3, R4, and R5 are downstream routers in the multicast LAN.

This example shows the configuration of the downstream devices: Routers R2, R3, R4, and R5.

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.

Step-by-Step Procedure

1. Configure PIM sparse mode on the interfaces.

   [edit]user@host# edit protocols pim[edit protocols pim]user@host# set rp static address 10.255.112.160[edit protocols pim]user@host# set interface all mode sparse version 2[edit protocols pim]user@host# set interface all version 2[edit protocols pim]user@host# set interface fxp0.0 disable

2. Enable the join suppression timer.

   [edit protocols pim]user@host# set reset-tracking-bit

3. Configure the prune override interval value.

   [edit protocols pim]user@host# set override-interval 4000

4. Configure the propagation delay of the link.

   [edit protocols pim]user@host# set propagation-delay 500

5. (Optional) Configure PIM tracing operations.

   [edit protocols pim]user@host# set traceoptions file pim.log size 5m world-readable[edit protocols pim]user@host# set traceoptions flag join detail[edit protocols pim]user@host# set traceoptions flag normal detail[edit protocols pim]user@host# set traceoptions flag register detail

6. If you are done configuring the device, commit the configuration.

   [edit protocols pim]user@host# commit

Results

From configuration mode, confirm your configuration by entering the show protocols command. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Verification

• show pim join extensive
• show multicast route extensive

Example: Configuring PIM Sparse Mode over an IPsec VPN

IPsec VPNs create secure point-to-point connections between sites over the Internet. The Junos OS implementation of IPsec VPNs supports multicast and unicast traffic. The following example shows how to configure PIM sparse mode for the multicast solution and how to configure IPsec to secure your traffic.

• M Series and T Series routers with one of the following PICs:
  • Adaptive Services (AS) PIC
  • Multiservices (MS) PIC
• JCS1200 platform with a Multiservices PIC (MS-500)

The tunnel endpoints do not need to be the same platform type. For example, the device on one end of the tunnel can be a JCS1200 router, while the device on the other end can be a standalone T Series router. The two routers that are the tunnel endpoints can be in the same autonomous system or in different autonomous systems.

In the configuration shown in this example, OSPF is configured between the tunnel endpoints. In Figure 3, the tunnel endpoints are R0 and R1. The network that contains the multicast source is connected to R0. The network that contains the multicast receivers is connected to R1. R1 serves as the statically configured rendezvous point (RP).

Figure 3: PIM Sparse Mode over an IPsec VPN

1. On R0, configure the incoming Gigabit Ethernet interface.
   [edit interfaces]user@host# set ge-0/1/1 description "incoming interface"user@host# set ge-0/1/1 unit 0 family inet address 10.20.0.1/30
2. On R0, configure the outgoing Gigabit Ethernet interface.
   [edit interfaces]user@host# set ge-0/0/7 description "outgoing interface"user@host# set ge-0/0/7 unit 0 family inet address 10.10.1.1/30
3. On R0, configure unit 0 on the sp- interface. The Junos OS uses unit 0 for service logging and other communication from the services PIC.
   [edit interfaces]user@host# set sp-0/2/0 unit 0 family inet
4. On R0, configure the logical interfaces that participate in the IPsec services. In this example, unit 1 is the inward-facing interface. Unit 1001 is the interface that faces the remote IPsec site.
   [edit interfaces]user@host# set sp-0/2/0 unit 1 family inetuser@host# set sp-0/2/0 unit 1 service-domain insideuser@host# set sp-0/2/0 unit 1001 family inetuser@host# set sp-0/2/0 unit 1001 service-domain outside
5. On R0, direct OSPF traffic into the IPsec tunnel.
   [edit protocols ospf]user@host# set area 0.0.0.0 interface sp-0/2/0.1user@host# set parea 0.0.0.0 interface ge-0/1/1.0 passiveuser@host# set area 0.0.0.0 interface lo0.0
6. On R0, configure PIM sparse mode. This example uses static RP configuration. Because R0 is a non-RP router, configure the address of the RP router, which is the routable address assigned to the loopback interface on R1.
   [edit protocols pim]user@host# set rp static address 10.255.0.156user@host# set interface sp-0/2/0.1user@host# set interface ge-0/1/1.0user@host# set interface lo0.0
7. On R0, create a rule for a bidirectional dynamic IKE security association (SA) that references the IKE policy and the IPsec policy.
   [edit services ipsec-vpn rule ipsec_rule]user@host# set term ipsec_dynamic then remote-gateway 10.10.1.2user@host# set term ipsec_dynamic then dynamic ike-policy ike_policyuser@host# set term ipsec_dynamic then dynamic ipsec-policy ipsec_policyuser@host# set match-direction input
8. On R0, configure the IPsec proposal. This example uses the Authentication Header (AH) Protocol.
   [edit services ipsec-vpn ipsec proposal ipsec_prop]user@host# set protocol ahuser@host# set authentication-algorithm hmac-md5-96
9. On R0, define the IPsec policy.
   [edit services ipsec-vpn ipsec policy ipsec_policy]user@host# set perfect-forward-secrecy keys group1user@host# set proposals ipsec_prop
10. On R0, configure IKE authentication and encryption details.
    [edit services ipsec-vpn ike proposal ike_prop]user@host# set authentication-method pre-shared-keysuser@host# set dh-group group1user@host# set authentication-algorithm md5user@host# set encryption-algorithm 3des-cbc
11. On R0, define the IKE policy.
    [edit services ipsec-vpn ike policy ike_policy]user@host# set proposals ike_propuser@host# set pre-shared-key ascii-text "$9$nuDo6CuREyvWxO1LNbsZGFn/AOR8LNws4"
12. On R0, create a service set that defines IPsec-specific information. The first command associates the IKE SA rule with IPsec. The second command defines the address of the local end of the IPsec security tunnel. The last two commands configure the logical interfaces that participate in the IPsec services. Unit 1 is for the IPsec inward-facing traffic. Unit 1001 is for the IPsec outward-facing traffic.
    [edit services service-set ipsec_svc]user@host# set ipsec-vpn-rules ipsec_ruleuser@host# set ipsec-vpn-options local-gateway 10.10.1.1user@host# set next-hop-service inside-service-interface sp-0/2/0.1user@host# set next-hop-service outside-service-interface sp-0/2/0.1001
13. On R1, configure the incoming Gigabit Ethernet interface.
    [edit interfaces]user@host# set ge-2/0/1 description "incoming interface"user@host# set ge-2/0/1 unit 0 family inet address 10.10.1.2/30
14. On R1, configure the outgoing Gigabit Ethernet interface.
    [edit interfaces]user@host# set ge-2/0/0 description "outgoing interface"user@host# set ge-2/0/0 unit 0 family inet address 10.20.0.5/30
15. On R1, configure the loopback interface.
    [edit interfaces]user@host# set lo0.0 family inet address 10.255.0.156
16. On R1, configure unit 0 on the sp- interface. The Junos OS uses unit 0 for service logging and other communication from the services PIC.
    [edit interfaces]user@host# set sp-2/1/0 unit 0 family inet
17. On R1, configure the logical interfaces that participate in the IPsec services. In this example, unit 1 is the inward-facing interface. Unit 1001 is the interface that faces the remote IPsec site.
    [edit interfaces]user@host# set sp-2/1/0 unit 1 family inetuser@host# set sp-2/1/0 unit 1 service-domain insideuser@host# set sp-2/1/0 unit 1001 family inetuser@host# set sp-2/1/0 unit 1001 service-domain outside
18. On R1, direct OSPF traffic into the IPsec tunnel.
    [edit protocols ospf]user@host# set area 0.0.0.0 interface sp-2/1/0.1user@host# set area 0.0.0.0 interface ge-2/0/0.0 passiveuser@host# set area 0.0.0.0 interface lo0.0
19. On R1, configure PIM sparse mode. R1 is an RP router. When you configure the local RP address, use the shared address, which is the address of R1’s loopback interface.
    [edit protocols pim]user@host# set rp local address 10.255.0.156user@host# set interface sp-2/1/0.1user@host# set interface ge-2/0/0.0user@host# set interface lo0.0 family inet
20. On R1, create a rule for a bidirectional dynamic Internet Key Exchange (IKE) security association (SA) that references the IKE policy and the IPsec policy.
    [edit services ipsec-vpn rule ipsec_rule]user@host# set term ipsec_dynamic from source-address 192.168.195.34/32user@host# set term ipsec_dynamic then remote-gateway 10.10.1.1user@host# set term ipsec_dynamic then dynamic ike-policy ike_policyuser@host# set term ipsec_dynamic then dynamic ipsec-policy ipsec_policyuser@host# set match-direction input
21. On R1, define the IPsec proposal for the dynamic SA.
    [edit services ipsec-vpn ipsec proposal ipsec_prop]user@host# set protocol ahuser@host# set authentication-algorithm hmac-md5-96
22. On R1, define the IPsec policy.
    [edit services ipsec-vpn ipsec policy ipsec_policy]user@host# set perfect-forward-secrecy keys group1user@host# set proposals ipsec_prop
23. On R1, configure IKE authentication and encryption details.
    [edit services ipsec-vpn ike proposal ike_prop]user@host# set authentication-method pre-shared-keysuser@host# set dh-group group1user@host# set authentication-algorithm md5user@host# set encryption-algorithm 3des-cbc
24. On R0, define the IKE policy.
    [edit services ipsec-vpn ike policy ike_policy]user@host# set proposals ike_propuser@host# set pre-shared-key ascii-text "$9$twR6pORrlMxNbhSds4aHkCtuBhr-dsoaU"
25. On R1, create a service set that defines IPsec-specific information. The first command associates the IKE SA rule with IPsec. The second command defines the address of the local end of the IPsec security tunnel. The last two commands configure the logical interfaces that participate in the IPsec services. Unit 1 is for the IPsec inward-facing traffic. Unit 1001 is for the IPsec outward-facing traffic.
    [edit services service-set ipsec_svc]user@host# set ipsec-vpn-rules ipsec_ruleuser@host# set ipsec-vpn-options local-gateway 10.10.1.2user@host# set next-hop-service inside-service-interface sp-2/1/0.1user@host# set next-hop-service outside-service-interface sp-2/1/0.1001

To verify the configuration, run the following commands:

Example: Configuring Multicast for Virtual Routers with IPv6 Interfaces

A virtual router is a type of simplified routing instance that has a single routing table. This example shows how to configure PIM in a virtual router.

• Requirements
• Overview
• Configuration
• Verification

Requirements

Before you begin, configure an interior gateway protocol or static routing. See the Junos OS Routing Protocols Configuration Guide.

Overview

You can configure PIM for the virtual-router instance type as well as for the vrf instance type. The virtual-router instance type is similar to the vrf instance type used with Layer 3 VPNs, except that it is used for non-VPN-related applications.

The virtual-router instance type has no VPN routing and forwarding (VRF) import, VRF export, VRF target, or route distinguisher requirements. The virtual-router instance type is used for non-Layer 3 VPN situations.

When PIM is configured under the virtual-router instance type, the VPN configuration is not based on RFC 2547, BGP/MPLS VPNs, so PIM operation does not comply with the Internet draft draft-rosen-vpn-mcast-07.txt, Multicast in MPLS/BGP VPNs. In the virtual-router instance type, PIM operates in a routing instance by itself, forming adjacencies with PIM neighbors over the routing instance interfaces as the other routing protocols do with neighbors in the routing instance.

1. On R1, configure a virtual router instance with three interfaces (ge-0/0/0.0, ge-0/1/0.0, and ge-0/1/1.0).
2. Configure PIM and the RP.
3. Configure an MLD static group containing interfaces ge-0/1/0.0 and ge-0/1/1.0.

After you configure this example, you should be able to send multicast traffic from R2 through ge-0/0/0 on R1 to the static group and verify that the traffic egresses from ge-0/1/0.0 and ge-0/1/1.0.

Note: Do not include the group-address statement for the virtual-router instance type.

Figure 4 shows the topology for this example.

Figure 4: Virtual Router Instance with Three Interfaces

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.

Step-by-Step Procedure

1. Configure the interfaces.

   [edit]user@host# edit interfaces[edit interfaces]user@host# set ge-0/0/0 unit 0 family inet6 address 2001:4:4:4::1/64[edit interfaces]user@host# set ge-0/1/0 unit 0 family inet6 address 2001:24:24:24::1/64[edit interfaces]user@host# set ge-0/1/1 unit 0 family inet6 address 2001:7:7:7::1/64[edit interfaces]user@host# exit

2. Configure the routing instance type.

   [edit]user@host# edit routing-instances[edit routing-instances]user@host# set mvrf1 instance-type virtual-router

3. Configure the interfaces in the routing instance.

   [edit routing-instances]user@host# set mvrf1 interface ge-0/0/0[edit routing-instances]user@host# set mvrf1 interface ge-0/1/0[edit routing-instances]user@host# set mvrf1 interface ge-0/1/1

4. Configure PIM and the RP in the routing instance.

   [edit routing-instances]user@host# set mvrf1 protocols pim rp local family inet6 address 2001:1:1:1::1

5. Configure PIM on the interfaces.

   [edit routing-instances]user@host# set mvrf1 protocols pim interface ge-0/0/0[edit routing-instances]user@host# set mvrf1 protocols pim interface ge-0/1/0[edit routing-instances]user@host# set mvrf1 protocols pim interface ge-0/1/1[edit routing-instances]user@host# exit

6. Configure the MLD group.

   [edit]user@host# edit protocols mld[edit protocols mld]user@host# set interface ge-0/1/0.0 static group ff0e::10[edit protocols mld]user@host# set interface ge-0/1/1.0 static group ff0e::10

7. If you are done configuring the device, commit the configuration.

   [edit routing-instances]user@host# commit

Results

Confirm your configuration by entering the show interfaces, show routing-instances, and show protocols commands.

Verification

To verify the configuration, run the following commands:

• show mld group
• show mld interface
• show mld statistics
• show multicast interface
• show multicast route
• show multicast rpf
• show pim interfaces
• show pim join
• show pim neighbors
• show route forwarding-table
• show route instance
• show route table