PIM

In this phase, a multicast receiver expresses its interest in receiving traffic destined for a multicast group. Typically it does this using IGMP, but other mechanisms may also serve this purpose. One of the local routers of the receiver is elected as the designated router (DR) for that subnet. When the expression of interest is received, the DR sends a PIM join message toward the RP for that multicast group. This join message is known as a (*,G) join because it joins group G for all sources to that group. The (*,G) join travels hop-by-hop toward the RP for the group, and in each router it passes through, the multicast tree state for group G is instantiated.

Eventually, the (*,G) join either reaches the RP or reaches a router that already has the (*,G) join state for that group. When many receivers join the group, their join messages converge on the RP and form a distribution tree for group G that is rooted at the RP. The distribution tree is called the RP tree or the shared tree (because it is shared by all sources sending to that group). Join messages are re-sent periodically as long as the receiver remains in the group. When all receivers on a leaf network leave the group, the DR sends a PIM (*,G) prune message toward the RP for that multicast group. However, if the prune message is not sent for any reason, the state eventually times out.

A multicast data sender starts sending data destined for a multicast group. The local router of the sender (the DR) takes these data packets, unicast-encapsulates them, and sends them directly to the RP. The RP receives these encapsulated data packets, removes the encapsulation, and forwards them to the shared tree. The packets then follow the (*,G) multicast tree state in the routers on the RP tree, and are replicated wherever the RP tree branches, and eventually reach all the receivers for that multicast group. The process of encapsulating data packets to the RP is called registering, and the encapsulation packets are known as PIM register packets.

At the end of phase one, multicast traffic is flowing encapsulated to the RP, and then natively over the RP tree to the multicast receivers.

In this phase, register-encapsulation of data packets is performed. However, register-encapsulation of data packets is inefficient for the following reasons:

• Encapsulation and de-encapsulation can be resource-intensive operations for a router to perform, depending on whether the router has appropriate hardware for the tasks.

• Traveling to the RP and then back down the shared tree can cause the packets to travel a relatively long distance to reach receivers that are close to the sender. For some applications, increased latency is unwanted.

Although register-encapsulation can continue indefinitely, for the previous reasons, the RP normally switches to native forwarding. To do this, when the RP receives a register-encapsulated data packet from source S on group G, it normally initiates an (S,G) source-specific join toward S. This join message travels hop-by-hop toward S, instantiating an (S,G) multicast tree state in the routers along the path.

The (S,G) multicast tree state is used only to forward packets for group G if those packets come from source S. Eventually, the join message reaches the S subnet or a router that already has the (S,G) multicast tree state, and packets from S start to flow following the (S,G) tree state toward the RP. These data packets can also reach routers with a (*,G) state along the path toward the RP, and if this occurs, they take a shortcut to the RP tree at this point.

While the RP is in the process of joining the source-specific tree for S, the data packets continue being encapsulated to the RP. When packets from S also start to arrive natively at the RP, the RP receives two copies of each of these packets. At this point, the RP starts to discard the encapsulated copy of these packets and sends a register-stop message back to the DR of S to prevent the DR from unnecessarily encapsulating the packets. At the end of phase two, traffic is flowing natively from S along a source-specific tree to the RP and from there along the shared tree to the receivers. Where the two trees intersect, traffic can transfer from the shared RP tree to the shorter source tree.

In this phase, the RP joins back toward the source using the shortest path tree (SPT). Although having the RP join back toward the source removes the encapsulation overhead, it does not completely optimize the forwarding paths. For many receivers, the route via the RP can involve a significant detour when compared with the shortest path from the source to the receiver.

To obtain lower latencies, a router on the LAN of the receiver, typically the DR, may optionally initiate a transfer from the shared tree to a source-specific SPT. To do this, it issues an (S,G) join toward S. This instantiates the (S,G) state in the routers along the path to S. Eventually, this join either reaches the S subnet or reaches a router that already has the (S,G) state. When this happens, data packets from S flow following the (S,G) state until they reach the receiver.

At this point, the receiver (or a router upstream of the receiver) is receiving two copies of the data—one from the SPT, and one from the RP tree. When the first traffic starts to arrive from the SPT, the DR or upstream router starts to drop the packets for G from S that arrive via the RP tree. In addition, it sends an (S,G) prune message toward the RP. The prune message travels hop-by-hop, instantiating an (S,G) state along the path toward the RP, indicating that traffic from S for G should not be forwarded in this direction. The prune message is propagated until it reaches the RP or a router that still needs the traffic from S for other receivers.

By now, the receiver is receiving traffic from S along the SPT between the receiver and S. In addition, the RP is receiving the traffic from S, but this traffic is no longer reaching the receiver along the RP tree. As far as the receiver is concerned, this is the final distribution tree.

The VRRP Aware PIM feature enables PIM to track the state of a VRRP instance and to identify whether the associated VRRP interface is the master. PIM uses an operational group option (oper-group group-name) to monitor the state of VRRP. One operational group can be created for IPv4, and another for IPv6. When VRRP is the MR, the operational group is up; for all other VRRP states, the operational group is down. A VRRP instance can only be associated with one operational group, and an operational group can have one or more associated VRRP instances. This feature is supported on base router, IES, and VPRN interfaces.

If the monitored interface is the VRRP MR, PIM becomes the DR by setting its priority to the configured oper-group active-priority value. For the router to become the DR, the correct priorities must be configured so the active priority of the oper-group is the highest priority on the IP interface.

If a PIM router is the DR and then receives an indication from VRRP that the interface is no longer the VRRP MR, PIM relinquishes the DR role by setting its priority back to the default or configured priority value.

If the configured VRRP instance or oper-group is not configured, PIM operates as normal with the default or configured priority value. A change in the operational group status is independent of the address family; IPv4 and IPv6 priorities are configured independently of each other. Two operational groups are supported per PIM interface, one for IPv4 and one for IPv6.

When configuring VRRP Aware PIM, consider the following recommendations:

• Configure VRRP to use BFD to speed up failure detection in addition to the functionality provided by VRRP Aware PIM.

• To optimize failover, enable the following command on the primary and secondary routers to make them a hot-standby redundant pair.

  configure router pim non-dr-attract-traffic

  Note: This configuration ignores the DR state and attracts traffic to populate the router’s PIM database. Do not use this configuration if multicast traffic must only follow the VRRP MR.

• Configure the group up time on the primary router and the group down time on the secondary router to the time needed to repopulate the PIM database; for example, 10 seconds. This allows the primary router to populate its PIM database again before becoming the DR and recover from the secondary back to the primary router if a failure occurs from the primary to secondary router. Use the following commands to configure the up and down times.

  configure service oper-group hold-time group up
  configure service oper-group hold-time group down

  Configure the up time on the secondary router to 0, so that it assumes the DR role immediately if the primary router fails. The up hold time is set to 4 seconds by default, which delays the DR change unnecessarily.

• Sticky DR enables the secondary router to continue to act as the DR after the primary router comes back up. Sticky DR is incompatible with the VRRP Aware PIM mechanism that tracks the VRRP MR. You should disable it if it is configured with the following command.

  configure router pim interface sticky-dr

The following example shows a basic configuration for VRRP Aware PIM.

[ex:/configure service]
A:admin@node-2# info
    interface "to-lan" {
        ipv4 {
            vrrp 1 {
                oper-group "VAwP1"
            }
        }
    }
    interface "to-lan2" {
        ipv4 {
            vrrp 1 {
                oper-group "VAwP2"
            }
        }
    }
    oper-group "VAwP1" {
    }
    oper-group "VAwP2" (
    }
    vprn "1" {
        customer "1"
        pim {
            interface "to-lan" {
                ipv4 {
                    monitor-oper-group {
                        name "VAwP1"
                        operation add
                        priority-delta 90
                    }
                }
                ipv6 {
                    monitor-oper-group {
                        name "VAwP1"
                        operation add
                        priority-delta 90
                    }
                }
            }
            interface "to-lan2" {
                ipv4 {
                    monitor-oper-group {
                        name "VAwP2"
                        operation add
                        priority-delta 90
                    }
                }
                ipv6 {
                    monitor-oper-group {
                        name "VAwP2"
                        operation add
                        priority-delta 90
                    }
                }
            }
        }
    }

A:node-2>config>service# info
----------------------------------------------
    oper-group ‟VAwP1” create
    oper-group ‟VAwP2” create   
    exit
    vprn 1 customer 1 create
        shutdown
        interface to-lan
            vrrp 1 create
                oper-group ‟VAwP1”
            exit 
         exit  
        interface to-lan2
            vrrp 1 create
                oper-group ‟VAwP2”
            exit 
         exit  
         pim
            interface to-lan
                monitor-oper-group ‟VAwP1” family ipv4 add 90
                monitor-oper-group ‟VAwP1” family ipv6 add 90
            exit
            interface to-lan2
                monitor-oper-group ‟VAwP2” family ipv4 add 90
                monitor-oper-group ‟VAwP2” family ipv6 set 90
            exit
      exit
exit

PIM SSM scaling can be increased to 256k (S,G)s using the pim-ssm-scaling command. This command enables (S,G) scaling for PIM SSM in the global routing table only. The current scaling limitation of (S,G)s per complex (FP) still exist. However, the 256K (S,G)s can be configured over multiple complex to achieve this higher scaling.

When PIM SSM scaling is enabled, the following multicast features are disabled:

• DM

• MoFRR

• JP policy

• SSM groups

• (S,G) programming is a maximum of 32000 per complex

• InBand features (BIER and MLDP)

• Extranet

• ASM

This feature is only supported on CPM5s.

When the pim-ssm-scaling command is enabled and there is a mix of FP3, FP4, and FP5 cards in the system, Nokia recommends that you configure the following command with the dynamic option to ensure the system dynamically chooses the lowest denominator throughput card as multicast-plane throughput.

• MD-CLI

  configure multicast-management chassis-level per-mcast-plane-capacity total-capacity dynamic 

• classic CLI

  configure mcast-management chassis-level per-mcast-plane-capacity total-capacity dynamic 

To achieve fast failover when PIM SSM scaling is enabled, the default MCID is used which results in the multicast traffic being sent to all line cards and silently discarded where there is no receiver for that traffic. Consequently, the maximum achievable plane capacity for this traffic is constrained to that of the lowest performance FP. When the maximum link capacity from the fabric to the lowest-performance FP is reached, the link to that FP is overloaded causing the fabric to back-pressure the ingress and resulting in packet loss for all FPs. By using the default MCID, this capacity constraint is independent of whether the lowest-performance FP has a receiver on it or not.

If the multicast management chassis per-plane total capacity is configured to an explicit value which is larger than that supported by the lowest-performance FP, IMPM believes there is more plane capacity available than there really is and the result is (S,G) packet loss instead of blackholing.

By setting the multicast management chassis per-plane total capacity to dynamic, the system automatically sets the switch fabric multicast plane capacity to the minimum value supported by the fabric and all line cards in the system. IMPM then has the correct view of the available plane capacity and correctly blackholes (S,G)s when insufficient plane capacity is available. The total maximum multicast capacity is still constrained by the lowest-performance FP.

When configuring PIM, make sure to enable PIM on all interfaces for the routing instance, otherwise multicast routing errors can occur.

Use the commands in the following context to configure PIM.

configure router pim

The following example displays a basic configuration with PIM enabled.

[ex:/configure router "Base" pim]
A:admin@node-2# info
    admin-state enable
    apply-to none
    rp {
        ipv4 {
            bsr-candidate {
                admin-state disable
                address 10.10.10.2
                priority 0
                hash-mask-len 30
            }
            rp-candidate {
                admin-state disable
                holdtime 150
                priority 192
                address 10.10.10.1
            }
            static {
                address 10.10.10.10 {
                }
                address 198.51.100.254 {
                    group-prefix 239.24.24.24/32 {
                }
            }
        }
    }

A:node-2>config>router# info
#------------------------------------------
echo "PIM Configuration"
#------------------------------------------
        pim
            apply-to none
            rp
                static
                    address 198.51.100.254
                        group-prefix 239.24.24.24/32
                    exit
                    address 10.10.10.10
                    exit
                exit
                bsr-candidate
                    shutdown
                    address 10.10.10.2
                    priority 0
                    hash-mask-len 30
                exit
                rp-candidate
                     shutdown
                     address 10.10.10.1
                     holdtime 150
                     priority 192
                exit
            exit
            no shutdown
        exit
------------------------------------------

You can reference router interfaces in the PIM configuration. You must create the interfaces first in the router context. Use the commands in the following context to configure and enable PIM router interfaces.

configure router pim interface

The following example shows a PIM configuration with basic interfaces configured.

[ex:/configure router "base" pim]
A:admin@node-2# info
    admin-state enable
    apply-to all
    interface "lax-sjc" {
        admin-state enable 
    }
    interface "lax-vls" {
        admin-state enable
    }
    interface "pl-ix" {
        admin-state enable
    }
    interface "system" {
        admin-state enable
    }
    rp {
        ipv4 {
            bsr-candidate {
                admin-state enable
                address 10.10.10.10
            }
            rp-candidate {
                admin-state enable
                address 10.10.10.1
            }
            static {
                address 10.10.10.1 {
                }
                address 198.51.100.254 {
                    group-prefix 239.24.24.24/32 { }
                }
            }
        }
    }

A:node-2>config>router>pim# info
----------------------------------------------
            interface "system"
                no shutdown
            exit
            interface "lax-sjc"
                no shutdown
            exit
            interface "lax-vls"
                no shutdown
            exit
            interface "pl-ix"
                no shutdown
            exit
            apply-to all
            rp
                static
                    address 10.10.10.1
                    exit
                    address 198.51.100.254
                        group-prefix 239.24.24.24/32
                    exit
                exit
                bsr-candidate
                    address 10.10.10.10
                    no shutdown
                exit
                rp-candidate
                    address 10.10.10.1
                    no shutdown
                exit
            exit
            no shutdown
----------------------------------------------

Join policies are used in Protocol Independent Multicast (PIM) configurations to prevent the transportation of multicast traffic across a network and the dropping of packets at a scope at the edge of the network. PIM Join filters reduce the potential for denial of service (DoS) attacks and PIM state explosion—large numbers of Joins forwarded to each router on the RPT, resulting in memory consumption. See the Importing PIM Join/Register Policies section of the Multicast Routing Guide for more information.

(*,G) or (S,G) is the information used to forward unicast or multicast packets. The following options can be configured:

• group-address

  This matches the group address policy in join/prune messages group-address ‟group-address-policy”.

• source-address

  This is the source-address (192.168.0.1) that matches the source address in join/prune messages.

• interface

  This matches any join message received on the specified interface, for example, interface port 1/1/1

• neighbor

  This matches any join message received from the specified neighbor; for example, neighbor 1.1.1.1

Use commands in the following context to configure policy options:

• MD-CLI

  configure policy-options

• classic CLI

  configure router policy-options

The following configuration example does not allow join messages for the specified group address prefix list and source 192.168.0.1 but allows other join messages.

[ex:/configure policy-options]
A:admin@cses-V208# info
    prefix-list "prefix-list-1" {
        prefix 192.0.2.0/24 type exact {
        }
    }
    policy-statement "Foo" {
        entry 10 {
            from {
                group-address "prefix-list-1"
                source-address {
                    ip-address 192.168.0.1
                }
            }
        }
    }

A:node-2>config>router>policy-options# info
----------------------------------------------
            prefix-list "prefix-list-1"
                prefix 192.0.2.0/24 exact
            exit
            policy-statement "Foo"
                entry 10
                    from
                        group-address "prefix-list-1"
                        source-address 192.168.0.1
                    exit
                exit
            exit
----------------------------------------------

An import mechanism is provided to control the (*,G) and (S,G) states that are created on the router.

Use the following commands to configure PIM join or register import policies.

configure router pim import join-policy
configure router pim import register-policy

The following example shows a PIM configuration with an imported policy applied. The policy would not allow join messages for group 229.50.50.208/32 and source 192.168.0.0/16 but would allow join messages for 192.168.0.0/16, 229.50.50.208 (see the ‟Configuring Route Policy Components” section of the 7705 SAR Gen 2 Unicast Routing Protocols Guide).

[ex:/configure router "base" pim]
A:admin@node-2# info
    ...
    apply-to-all true
    import join-policy "foo"
    interface "lax-sjc" {
        admin-state enable
    }
    interface "lax-vls" {
        admin-state enable
    }
    interface "pl-ix" {
        admin-state enable
    }
    interface "system" {
        admin-state enable
    }
    rp {
        ipv4 {
            bsr-candidate {
                admin-state enable
                address 10.10.10.10
            }
            rp-candidate {
                admin-state enable
                address 10.10.10.1
            }
            static {
                address 10.10.10.1 {
                }
                address 198.51.100.254 {
                    group-prefix 239.24.24.24/32 { }
                }
            }
        }
    }
    ...

A:node-2>config>router>pim# info
----------------------------------------------
            ...
            import join-policy "foo"
            interface "system"
            exit
            interface "lax-sjc"
            exit
            interface "lax-vls"
            exit
            interface "pl-ix"
            exit
            apply-to all
            rp
                static
                    address 10.10.10.1
                    exit
                    address 198.51.100.254
                        group-prefix 239.24.24.24/32
                    exit
                exit
                bsr-candidate
                    address 10.10.10.10
                    no shutdown
                exit
                rp-candidate
                    address 10.10.10.1
                    no shutdown
                exit
            exit
            ...
----------------------------------------------

Bootstrap import and export policies are used to control the flow of bootstrap messages to and from the RP.

The following configuration example specifies that no BSR messages are received or sent out of interface port 1/1/1.

[ex:/configure policy-options]
A:admin@node-2# info
    ...
    prefix-list "pim-policy-1" {
        prefix 10.0.0.0/16 longer  
        prefix 10.10.186.0/24 longer
    }     
    prefix-list "pim-policy-2"  {
        prefix 10.1.0.0/16 longer
    }
    policy-statement "pim-export-policy" {
        entry 10 {
            to {
                prefix-list "pim-policy-1" "pim-policy-2"
            }
            action {
                action-type reject
            }
        }
    }
    policy-statement "pim-import-policy" {
        entry 10 {
            from {
                interface ["port1"]
            }
            action {
                action-type reject
            }
        }
    }
    ...

A:node-2>config>router>policy-options# info
----------------------------------------------
        ...
        prefix-list "pim-policy-1" 
            prefix 10.0.0.0/16 longer  
            prefix 10.10.186.0/24 longer
        exit     
        prefix-list "pim-policy-2"  {
            prefix 10.1.0.0/16 longer
        exit
        policy-statement "pim-import-policy"
            entry 10
                from
                    interface "port1"
                exit
                action drop
                exit
            exit
        exit
        policy-statement "pim-export-policy"
            entry 10
                to
                    prefix-list "pim-policy-1" "pim-policy-2"
                exit
                action accept
            exit
        exit
        ... 

[ex:/configure router "Base" pim]
A:node-2# info
    admin-state enable
    apply-to all
    interface "lax-sjc" {
    }
    interface "lax-vls" {
    }
    interface "pl-ix" {
    }
    interface "system" {
    }
    rp {
        bootstrap {
            import ["pim-import"]
        }
        bootstrap {
            export ["pim-export"]
        }
        ipv4 {
            bsr-candidate {
                admin-state disable
                priority 0
                address 10.10.10.10
                hash-mask-len 30
            }
            rp-candidate {
                admin-state enable
                address 10.10.10.1
            }
            static {
                address 10.10.10.1 {
                }
                address 198.51.100.254 {
                    group-prefix 239.24.24.24/32 { }
                }
            }
        }
    }

A:node-2>config>router>pim# info
----------------------------------------------
            interface "system"
            exit
            interface "lax-sjc"
            exit
            interface "lax-vls"
            exit
            interface "pl-ix"
            exit
            apply-to all
            rp
                bootstrap-import "pim-import"
                bootstrap-export "pim-export"
                static
                    address 10.10.10.1
                    exit
                    address 198.51.100.254
                        group-prefix 239.24.24.24/32
                    exit
                exit
                bsr-candidate
                    shutdown
                    address 10.10.10.10
                exit
                rp-candidate
                    address 10.10.10.1
                    no shutdown
                exit
            exit
            no shutdown
----------------------------------------------