• Related Topics
• clear pim join-distribution in the Protocols Command Reference

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 and add to the multicast data tree. 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 towards a source. PIM join load balancing is only supported for PIM sparse mode configurations.

Note: 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).

Note: If an IBGP multipath forwarding VPN route is available, Junos uses the multipath forwarding VPN route to send join messages to the remote PE routers to achieve load balancing over the VPN.

You can include this statement at the following hierarchy levels:

• [edit protocols pim]
• [edit routing-instances routing-instance-name protocols pim]
• [edit logical-systems logical-system-name protocols pim]
• [edit logical-systems logical-system-name routing-instances routing-instance-name protocols pim]

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 and not on a per-source basis. Therefore, there is no guarantee that joins for a particular source will be load-balanced, but the joins for all sources and all groups known to the routing device will be 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 find out 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.

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.

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.

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 join extensive command now have nonzero join counts. If the counts differ by more than one and were zero when load balancing commenced, there is an error (joins prior to load balancing are not redistributed). The join count also appears in the show pim neighbors detail output:

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 Juniper Networks recommends that you perform PIM join redistribution during a maintenance window.

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.

When new links are added or a failed link is restored, the existing PIM join states are not redistributed to the new link. New flows will be distributed to the new links. However, in a network without new joins and prunes, the new link is not used for multicast traffic. The clear pim join-distribution command redistributes the existing flows to the new upstream neighbors. Redistributing the existing flows causes traffic to be disrupted, so Juniper Networks recommends that you run the clear pim join-distribution command during a maintenance window.