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 anycast RP for PIM-SM implementation is defined in RFC 4610, Anycast-RP Using Protocol Independent Multicast (PIM), and is similar to that described in RFC 3446, Anycast Rendezvous Point (RP) Mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP). The implementation extends the register mechanism in PIM so that anycast RP functionality can be retained without using MSDP.

The mechanism works as follows:

• An IP address is chosen as the RP address. This address is statically configured or distributed using a dynamic protocol to all PIM routers throughout the domain.

• A set of routers in the domain are chosen to act as RPs for this RP address. These routers are called the anycast-RP set.

• Each router in the anycast-RP set is configured with a loopback interface using the RP address.

• Each router in the anycast-RP set also needs a separate IP address to be used for communication between the RPs.

• The RP address, or a prefix that covers the RP address, is injected into the unicast routing system inside the domain.

• Each router in the anycast-RP set is configured with the addresses of all other routers in the anycast-RP set. This must be consistently configured for all RPs in the set.

The following figure shows a scenario where all routers are connected, and where R1A, R1B, and R2 are receivers for a group, and S1 and S2 send to that group. In the example, RP1, RP2, and RP3 are all assigned the same IP address that is used as the anycast-RP address (RPA).

The following procedure is used when S1 starts sourcing traffic.

1. S1 sends a multicast packet.

2. The DR directly attached to S1 forms a PIM register message to send to the RPA. The unicast routing system delivers the PIM register message to the nearest RP, in this case RP1.

3. RP1 receives the PIM register message, de-encapsulates it, and sends the packet down the shared tree to receivers R1A and R1B.

4. RP1 is configured with the IP addresses of RP2 and RP3. Because the register message did not come from one of the RPs in the anycast-RP set, RP1 assumes the packet came from a DR. If the register message is not addressed to the RPA, an error has occurred and it should be rate-limited logged.

5. RP1 sends a copy of the register message from the DR of S1 to both RP2 and RP3. RP1 uses its own IP address as the source address for the PIM register message.

6. RP1 may join back to the source tree by triggering an (S1,G) join message toward S1; however, RP1 must create an (S1,G) state.

7. RP2 receives the register message from RP1, de-encapsulates it, and also sends the packet down the shared tree to receiver R2.

8. RP2 sends a register-stop message back to RP1. RP2 may wait to send the register-stop message if it decides to join the source tree. RP2 should wait until it has received data from the source on the source tree before sending the register-stop message. If RP2 decides to wait, the register-stop message is sent when the next register is received. If RP2 decides not to wait, the register-stop message is sent immediately.

9. RP2 may join back to the source tree by triggering an (S1,G) join message toward S1; however, RP2 must create an (S1,G) state.

10. RP3 receives the register message from RP1 and de-encapsulates it, but because there are no receivers joined for the group, it discards the packet.

11. RP3 sends a register-stop message back to RP1.

12. RP3 creates an (S1,G) state so when a receiver joins after S1 starts sending, RP3 can join quickly to the source tree for S1.

13. RP1 processes the register-stop messages from RP2 and RP3. RP1 may cache–on a per-RP/per-(S,G) basis—the receipt of register-stop messages from the RPs in the anycast-RP set. This option is performed to increase the reliability of register message delivery to each RP. When this option is used, subsequent register messages received by RP1 are sent only to the RPs in the anycast-RP set that have not previously sent register-stop messages for the (S,G) entry.

14. RP1 sends a register-stop message back to the DR the next time a register message is received from the DR and, when the option in step 13 is in use, if all RPs in the anycast-RP set have returned register-stop messages for a particular (S,G) route.

The procedure for S2 sending follows these same steps, but it is RP3 that sends a copy of the register originated by the DR of S2 to RP1 and RP2. Therefore, this example shows how sources anywhere in the domain, associated with different RPs, can reach all receivers, also associated with different RPs, in the same domain.

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.

Single area PIM signaling over BIER scenario shows a scenario in which the PIM domains and the BIER domain (including the source and the hosts) are all in a single area. The source can be directly connected to the EBBR. In this case, the EBBR is the source of the route for multicast source, or on the EBBR a static route can be configured for the multicast source and this is re-distributed into the IGP.

Multiple area PIM signaling over BIER scenario - core area shows a scenario in which the EBBR and IBBR are part of the core (backbone) area.

As in the single area scenario, the IBBR attempts to resolve the source IP address, and the IGP calculates the SPF tree to the source. IGP finds that the source IP address (S1) is generated using ABR routers P1 or P3 because these routers are the source routers for S1.

If the EBBR is not the ABR router, the rules of the single area scenario persists and a static route to the multicast source is required. If the EBBR is an ABR, a static route is not required.

Multiple area PIM signaling over BIER scenario - core AS shows a scenario in which the BIER domain is in the core AS instead of the core area. The core AS consists of a single area.

The EBBR and IBBRs can be any router in the core AS/area. BGP redistributes its routes into the IGP routers P1, P2, P3, and P4.

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 7450 ESS, 7750 SR, 7950 XRS, and VSR 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
----------------------------------------------