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 alternatives interfaces available, the multicast load is concentrated on one upstream interface and router.

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

To configure join load balancing for PIM sparse mode, include the join-load-balance statement:

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 router 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.

This example configures join load balancing for PIM sparse mode:

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 the 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. The counts should never differ by more than one if they were zero when load balancing commenced (joins prior to load balancing are not redistributed). 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.

When PIM join load balancing is enabled in a multicast VPN scenario with point-to-multipoint (P2MP) tunnels, the load balancing is achieved based on the join counts for the far-end PE routers, not for any intermediate P routers.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.