Implementing Multicast Service Reflection

This chapter contains the following topics:

Multicast service reflection

Multicast service reflection is a Cisco networking feature that

  • provides the capability for users to translate externally received multicast or unicast destination addresses to multicast or unicast addresses that conform to their organization's internal addressing policy

  • eliminates the need to redistribute unicast routes from external sources at the translation boundary into network infrastructure for Reverse Path Forwarding (RPF) to work properly, and

  • allows users to receive identical feeds from two ingress points in the network and route them independently.

Prerequisites for implementing multicast service reflection

Complete these prerequisites before implementing multicast service reflection:

  • Configure your multicast-enabled network with the necessary infrastructure to run either Protocol Independent Multicast Sparse Mode (PIM-SM), Bidirectional PIM (bidir-PIM), or PIM Source Specific Multicast (PIM-SSM). The configuration process may include configuring RPs, interface boundaries, or SSM ranges.

  • Confirm that the virtual interface for multicast service reflection (Vif1 interface) is installed in your border router and the Multicast Service Reflection application is installed and operational.

  • Each active receiver must initiate an Internet Group Management Protocol (IGMP) join to the multicast group that is defined on the router in the PIM domain.

Restrictions for implementing multicast service reflection

Be aware of these restrictions when implementing multicast service reflection:

  • When translating groups of multicast packets that are destined for the same multicast group but are originating from different sources, as in the case when using PIM-SSM, all multicast packets destined for a particular SSM group will get mapped to a single (S, G) after translation has occurred. For example, if (10.1.1.1, 232.1.1.1) and (10.1.1.2, 232.1.1.1) need to be translated, they will appear as a single entry, for example, (92.168.1.2, 232.239.1.1), where 192.168.1.2 is an IP address that resides in the Vif1 IP subnet.

  • PIM/IGMP control packets are not translated.

  • The following types of translation are not supported in Cisco IOS XE software:

    • Unicast-to-Multicast Destination Translation

    • Unicast-to-Multicast Destination Splitting

  • The use of a sub-interface as an input-interface has not been tested on platforms that are based on mcp_dev.

Information about implementing multicast service reflection

This reference provides the necessary configuration requirements and operational considerations for implementing multicast service reflection in network environments.

Benefits of implementing multicast service reflection

Benefits of implementing multicast service reflection are networking advantages that

  • allow users to translate externally received multicast or unicast destination addresses to multicast or unicast addresses that conform to their company's internal addressing policy,

  • provide logical separation between private and public multicast networks, and

  • provide flexibility to forward multicast packets--translated or untranslated--out the same outgoing interface.

Additional multicast service reflection benefits

Multicast service reflection offers these additional capabilities:

  • Provides redundancy by allowing users to get identical feeds from two ingress points in the network and route them independently.

  • Allows users to use the subnet of their choice to be the source network and scope it appropriately.

The address translation capability supports these types of translations:

  • Multicast-to-Multicast Destination Translation

  • Multicast-to-Unicast Destination Translation

  • Multicast-to-Multicast Destination Splitting

  • Multicast-to-Unicast Destination Splitting

Rendezvous points

A Rendezvous Point (RP) is a role that a router performs that

  • operates in PIM-SM or bidirectional PIM

  • acts as the meeting place for sources and receivers of multicast data, and

  • enables forwarding of traffic only to network segments with active receivers that have explicitly requested multicast data in PIM-SM.

RP operation in PIM-SM networks

In a PIM-SM network, the RP facilitates multicast distribution through this process:

  1. First hop designated routers with directly connected sources initially send their traffic to the RP.

  2. This traffic is then forwarded to receivers down a shared distribution tree.

  3. By default, when the last hop router with a directly connected receiver receives traffic from the shared tree, it immediately performs a shortest path tree switchover and sends a Join message towards the source, creating a source-based distribution tree between the source and the receiver.


Note

An RP is required only in networks running PIM-SM or bidirectional PIM.
PIM sparse mode

PIM sparse mode (PIM-SM) is a multicast routing protocol that

  • uses a pull model to deliver multicast traffic

  • delivers traffic only to network segments with active receivers that have explicitly requested the data

  • requires the use of a rendezvous point (RP) for shared tree operation

PIM sparse mode operation

Unlike dense mode interfaces, sparse mode interfaces are added to the multicast routing table only when periodic Join messages are received from downstream routers, or when a directly connected member is on the interface. When forwarding from a LAN, sparse mode operation occurs if an RP is known for the group. If so, the packets are encapsulated and sent toward the RP. When no RP is known, the packet is flooded in a dense mode fashion. If the multicast traffic from a specific source is sufficient, the first hop router of the receiver may send Join messages toward the source to build a source-based distribution tree.

PIM-SM distributes information about active sources by forwarding data packets on the shared tree. Because PIM-SM uses shared trees (at least, initially), it requires the use of a rendezvous point (RP). The RP must be administratively configured in the network.

In sparse mode, a router assumes that other routers do not want to forward multicast packets for a group, unless there is an explicit request for the traffic. When hosts join a multicast group, the directly connected routers send PIM Join messages toward the RP. The RP tracks multicast groups. Hosts that send multicast packets are registered with the RP by the first hop router of that host. The RP then sends Join messages toward the source. At this point, packets are forwarded on a shared distribution tree. If the multicast traffic from a specific source is sufficient, the first hop router of the host may send Join messages toward the source to build a source-based distribution tree.

First-hop designated routers with directly connected sources register with the RP and then data is forwarded down the shared tree to the receivers. The edge routers learn about a particular source when they receive data packets on the shared tree from that source through the RP. The edge router then sends PIM (S, G) Join messages toward that source. Each router along the reverse path compares the unicast routing metric of the RP address to the metric of the source address. If the metric for the source address is better, it will forward a PIM (S, G) Join message toward the source. If the metric for the RP is the same or better, then the PIM (S, G) Join message will be sent in the same direction as the RP. In this case, the shared tree and the source tree would be considered congruent.

If the shared tree is not an optimal path between the source and the receiver, the routers dynamically create a source tree and stop traffic from flowing down the shared tree. This behavior is the default behavior in Cisco IOS software. Network administrators can force traffic to stay on the shared tree by using the Cisco IOS ip PIM spt-threshold infinity command.

PIM-SM scales well to a network of any size, including those with WAN links. The explicit join mechanism prevents unwanted traffic from flooding the WAN links.

Vif1 interface

A Vif1 interface is a logical IP interface that

  • remains always up when the router is active, similar to a loopback interface

  • resides on its own unique subnet that should be advertised in Interior Gateway Protocol (IGP) updates (RIP, EIGRP, OSPF, ISIS), and

  • maintains information about the input interface, private-to-public mgroup mappings, mask length, which defines your pool range, and the source of the translated packet.

Multicast service reflection application

A multicast service reflection application is a Cisco IOS software application that

  • runs in Cisco IOS software interrupt level switching and processes packets forwarded to the Vif1 interface

  • translates both source and destination addresses, unlike IP multicast Network Address Translation (NAT) which only translates the source IP address, and

  • enables users who have not yet moved to the new multicast group to receive the untranslated stream.

Implementation and operation

Multicast service reflection is implemented using an interface CLI statement. Each configured multicast service reflection CLI statement establishes a packet match and rewrite operation acting on packets sent by Cisco IOS unicast or multicast packet routing onto the Vif1 interface. The matched and rewritten packet is sent back into Cisco IOS unicast or multicast packet routing, where it is handled like any other packet arriving from an interface.

The Vif1 interface is a receiver for the original stream and makes it appear that the new stream is coming from a source directly connected to the Vif1 subnet. The Vif1 interface is a Designated Router (DR) for active sources and registers with the appropriate RP.

More than one multicast service reflection operation can be configured to match the same packets, which allows you to replicate the same received traffic to multiple destination addresses.

How to implement multicast service reflection

This reference provides the necessary configuration steps and procedures to implement multicast service reflection.

Configure multicast service reflection

Use this task to configure multicast service reflection to match and rewrite multicast packets on interfaces, enabling packet matching and rewriting on multicast interfaces.

Procedure

Step 1

Use the ip multicast-routing [distributed] command to enable IP multicast routing.

Use the distributed keyword to enable the Multicast Distributed Switching feature.

Example:
Router(config)# ip multicast-routing

Step 2

Use the interface type number command to enter interface configuration mode for the specified interface type and number.

Example:
Router(config)# interface ethernet 0

Step 3

Use the ip pim sparse-mode command to enable PIM sparse mode on the interface.

Example:
Router(config-if)# ip pim sparse-mode

Step 4

Use the no shutdown command to enable the interface.

Example:
Router(config-if)# no shutdown

  1. Use the exit command to exit interface configuration mode and return to global configuration mode.

    Example:
    Router(config-if)# exit

Repeat Step 4 through Step 7 for each PIM interface.

Step 5

Use the interface Vif1 command to enter interface configuration mode for the Vif1 interface.

Example:
Router(config)# interface Vif1

Step 6

Use the ip address ip-address mask [secondary] command to set a primary or secondary IP address for the interface.

Example:
Router(config-if)# ip address 10.1.1.1 255.255.255.0

Step 7

Use the ip pim sparse-mode command to enable PIM sparse mode on the interface.

Example:
Router(config-if)# ip pim sparse-mode

Step 8

Use the ip service reflect input-interface destination destination-address to new-destination-address mask-len number source new-source-address command to match and rewrite multicast packets routed onto the Vif1 interface.

The matched and rewritten packets are sent back into Cisco multicast packet routing (or unicast routing if the destination is unicast), where they are handled like any other packets arriving from an interface.

Example:
Router(config-if)# ip service reflect ethernet0 destination 224.1.1.0 to 239.2.2.0 mask-len 24 source 10.1.1.2

Step 9

Use the ip igmp static-group {* | group-address source {source-address | ssm-map}} command to configure the router as a statically connected member of the specified group on the interface, and to forward traffic destined for the multicast group onto the interface.

This step is applicable only for multicast-to-multicast and multicast-to-unicast scenarios.

Example:
Router(config-if)# ip igmp static-group 224.1.1.1

Multicast service reflection is configured, and the router can match and rewrite multicast packets on the specified interfaces.

Configuration examples for multicast service reflection

This topic provides configuration examples for implementing multicast service reflection to assist in network setup.

See the following examples.

Example multicast-to-multicast destination translation

This example shows how to implement multicast service reflection (multicast-to-multicast destination translation) in a service provider network. Multicast-to-Multicast Destination Translation allows service providers to translate externally received content provider multicast destination addresses to multicast destination addresses that conform to the service provider's internal addressing policy.

This example uses the topology illustrated in the figure.

Figure 1. Multicast service reflection (Multicast-to-Multicast destination translation) in a service provider network example topology
The diagram illustrates the multicast-to-multicast destination translation process in a service provider network, showing how externally received multicast addresses are translated to conform to internal addressing policies. It depicts the flow of financial market information from a content provider to the service provider.

In this example topology, a content provider is sending financial market information to a service provider, which in turn is sending that information to active receivers (brokerage houses). The service provider may be receiving market data from multiple content providers.

Router R1 is an edge router in the service provider's PIM domain.

Router R1 has a loopback interface and is acting as the RP for the 224.1.1.0/24 address range.

Router R1 has a Vif1 interface and is running the multicast service reflection application.

Router R2 has a loopback interface and is acting as the RP for the 239.2.2.0/24 address range.

Enter these commands on the router running the multicast service reflection application (R1):

!
configure terminal
ip multicast-routing
interface <all IP numbered interfaces>
ip pim sparse-mode
no shutdown
!
! Configure the loopback interface for the Service Provider RP
!
interface loopback 0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
!
ip pim rp-address 192.168.2.1 mcast-content-provider-groups override
ip pim rp-address 192.168.2.2 mcast-service-provider-groups override
ip access-list standard mcast-content-provider-groups permit 224.1.1.0 0.0.0.255
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
!
! Configure the Vif1 virtual interface for multicast service reflection
!
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
ip service reflect Ethernet 0 destination 224.1.1.0 to 239.2.2.0 mask-len 24 source 10.1.1.2
ip igmp static-group 224.1.1.0
ip igmp static-group 224.1.1.1
ip igmp static-group 224.1.1.2
ip igmp static-group 224.1.1.3
.
.
.
ip igmp static-group 224.1.1.255

Enter these commands on the router that is the RP in the service provider network (R2):


ip multicast-routing
interface <all IP numbered interfaces>
ip pim sparse-mode
no shutdown
!
interface loopback 0
ip address 192.168.2.2 255.255.255.255
ip pim sparse-mode
!
ip pim rp-address 192.168.2.2 mcast-service-provider-groups override
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
!

Enter these commands on all the other routers in the service provider network (R3):


ip multicast-routing
interface <all IP numbered interfaces>
ip pim sparse-mode
no shutdown
!
ip pim rp-address 192.168.2.2 mcast-service-provider-groups override
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
end

Example multicast-to-unicast destination translation

This example shows how to implement multicast service reflection (multicast-to-unicast destination translation) in a service provider network. Multicast-to-Unicast Destination Translation allows service providers to translate externally received content provider multicast destination addresses to unicast destination addresses that conform to the service provider's internal addressing policy.

This example uses the topology illustrated in the figure.

Figure 2. Multicast service reflection (Multicast-to-Unicast destination translation) in a service provider network example topology
The diagram illustrates the process of multicast-to-unicast destination translation in a service provider network, showing how multicast addresses from a content provider are converted to unicast addresses for internal use.

In this example topology, a content provider is sending financial market information to a service provider, which in turn is sending that information to active receivers (brokerage houses). The service provider may be receiving market data from multiple content providers.

Router R1 is an edge router in the service provider's PIM domain.

Router R1 has a loopback interface and is acting as the RP for the 224.1.1.0/24 address range.

Router R1 has a Vif1 interface and is running the multicast service reflection application.

Routers R2 and R3 are non PIM enabled routers running unicast routing only in the service provider network.

Enter these commands on the router running the multicast service reflection application (R1):


configure terminal
ip multicast-routing
interface <all IP numbered interfaces>
ip pim sparse-mode
no shutdown
!

! Configure the loopback interface for the Service Provider RP
!
interface loopback 0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
!
ip pim rp-address 192.168.2.1 mcast-content-provider-groups override
ip access-list standard mcast-content-provider-groups permit 224.1.1.10 0.0.0.255
!

! Configure the Vif1 virtual interface for multicast service reflection
!
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
ip service reflect Ethernet 0 destination 224.1.1.0 to 10.3.3.0 mask-len 24 source 10.1.1.2
end

Configure multicast-to-multicast destination splitting

Implement multicast service reflection (multicast-to-multicast destination splitting) in a service provider network to translate externally received content provider multicast destination addresses to multiple multicast destination addresses that conform to the service provider's internal addressing policy.

This configuration allows service providers to translate externally received content provider multicast destination addresses to multiple multicast destination addresses that conform to the service provider's internal addressing policy. In this scenario, a content provider is sending financial market information to a service provider, which in turn is sending that information to active receivers (brokerage houses). The service provider may be receiving market data from multiple content providers.

Figure 3. Multicast service reflection (Multicast-to-Multicast destination splitting) in a service provider network example topology
The diagram illustrates the process of multicast-to-multicast destination splitting, showing how a service provider translates external multicast addresses from content providers to multiple internal addresses for distribution to active receivers.

  • Router R1 is an edge router in the service provider's PIM domain

  • Router R1 has a loopback configured and is acting as an RP for the 224.1.1.0/24 address range

  • Router R1 has a Vif1 interface and is running the multicast service reflection application

  • Routers R2 and R4 have multiple loopback interfaces and are acting as anycast RPs for the 239.2.2.0 and 239.3.3.0 address ranges

  • Router R3 and R5 are edge routers in the service provider's PIM domain

Procedure

Step 1

Configure the router running the multicast service reflection application (R1).

Example:
configure terminal
ip multicast-routing
interface &lt;all IP numbered interfaces&gt;
ip pim sparse-mode
no shutdown
!

Step 2

Configure the loopback interface for the service provider RP on R1.

Example:
! Configure the loopback interface for the Service Provider RP
interface loopback 0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
ip pim rp-address 192.168.2.1 mcast-content-provider-groups override
ip pim rp-address 192.168.0.254 mcast-service-provider-groups override
ip access-list standard mcast-content-provider-groups permit 224.1.1.0 0.0.0.255
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
ip access-list standard mcast-service-provider-groups permit 239.3.3.0 0.0.0.255
!

Step 3

Configure the Vif1 virtual interface for multicast service reflection on R1.

Example:
! Configure the Vif1 virtual interface for multicast service reflection
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
ip service reflect Ethernet 0 destination 224.1.1.0 to 239.2.2.0 mask-len 24 source 10.1.1.2
ip service reflect Ethernet 0 destination 224.1.1.0 to 239.3.3.0 mask-len 24 source 10.1.1.2
ip igmp static-group 224.1.1.0
ip igmp static-group 224.1.1.1
ip igmp static-group 224.1.1.2
ip igmp static-group 224.1.1.3
ip igmp static-group 224.1.1.254

Step 4

Configure the R2 router that is an anycast RP in the service provider network.

Example:
ip multicast-routing
interface &lt;all IP numbered interfaces&gt;
ip pim sparse-mode
no shutdown
interface loopback 0
ip address 192.168.2.2 255.255.255.255
ip pim sparse-mode
interface loopback 1
description --- Anycast RP ---
ip address 192.168.0.254 255.255.255.255
ip pim sparse-mode
ip msdp peer 192.168.2.3 connect-source Loopback0
ip msdp originator-id Loopback0
ip pim rp-address 192.168.0.254 mcast-service-provider-groups override
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
ip access-list standard mcast-service-provider-groups permit 239.3.3.0 0.0.0.255

Step 5

Configure the R4 router that is an anycast RP in the service provider network.

Example:
ip multicast-routing
interface &lt;all IP numbered interfaces&gt;
ip pim sparse-mode
no shutdown
!
interface loopback 0
ip address 192.168.2.3 255.255.255.255
ip pim sparse-mode
interface loopback 1
ip address 192.168.0.254 255.255.255.255
ip pim sparse-mode
!
ip pim rp-address 192.168.0.254 mcast-service-provider-groups override
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
ip access-list standard mcast-service-provider-groups permit 239.3.3.0 0.0.0.255
!
ip msdp peer 192.168.2.2 connect-source Loopback0
ip msdp originator-id Loopback0

Step 6

Configure the R3 and R5 routers in the service provider network.

Example:
ip multicast-routing
ip pim rp-address 192.168.0.254 mcast-service-provider-groups override
ip access-list standard mcast-service-provider-groups permit 239.2.2.0 0.0.0.255
permit 239.3.3.0 0.0.0.255
!

The multicast service reflection configuration is complete. The service provider can now translate externally received content provider multicast destination addresses to multiple multicast destination addresses that conform to the internal addressing policy, allowing the single multicast stream to be converted into two unique multicast streams.

Example multicast-to-unicast destination splitting

This example shows how to implement multicast service reflection (multicast-to-unicast destination splitting where the multicast single stream is converted into two unique unicast streams) in a service provider network. Multicast-to-Unicast Destination Splitting allows service providers to translate externally received content provider multicast destination addresses to multiple unicast destination addresses that conform to the service provider's internal addressing policy.

This example uses the topology illustrated in this figure.

Figure 4. Multicast service reflection (Multicast-to-Unicast destination splitting) in a service provider network example topology
The topology illustrates a content provider transmitting financial market information to a service provider, which then distributes it to active receivers. Router R1 serves as an edge router and a rendezvous point for multicast traffic in the service provider's PIM domain.

In this example topology, a content provider is sending financial market information to a service provider, which in turn is sending that information to active receivers (brokerage houses). The service provider may be receiving market data from multiple content providers.

Router R1 is an edge router in the service provider's PIM domain.

Router R1 is acting as a RP for the 224.1.1.0/24 address range.

Router R1 has a Vif1 interface and is running the multicast service reflection application.

Routers R2, R3, R4 and R5 are not PIM enabled and are running unicast routing only in the service provider network.

Enter these commands on the router running the multicast service reflection application (R1):

configure terminal
ip multicast-routing
interface &lt;all IP numbered interfaces&gt;
ip pim sparse-mode
no shutdown
!
! Configure the loopback interface for the Service Provider RP
!
interface loopback 0
ip address 192.168.2.1 255.255.255.255
ip pim sparse-mode
!
ip pim rp-address 192.168.2.1 mcast-content-provider-groups override
ip access-list standard mcast-content-provider-groups permit 224.1.1.0 0.0.0.255
!
! Configure the Vif1 virtual interface for multicast service reflection
!
interface Vif1
ip address 10.1.1.1 255.255.255.0
ip pim sparse-mode
ip service reflect Ethernet 0 destination 224.1.1.0 to 10.3.3.0 mask-len 24 source 10.1.1.2
ip service reflect Ethernet 0 destination 224.1.1.0 to 10.5.5.0 mask-len 24 source 10.1.1.2
ip igmp static-group 224.1.1.0
ip igmp static-group 224.1.1.1
ip igmp static-group 224.1.1.2
ip igmp static-group 224.1.1.3
.
.
.
ip igmp static-group 224.1.1.255
!
end

Configure PIMv6 Anycast RP solution

Use this task to configure PIMv6 anycast RP1 and RP2 peers.

Procedure

Step 1

Configure RP1 using the given steps.

  1. Use the ipv6 address [ipv6-address/prefix-length | prefix-name sub-bits /prefix-length ] to configure an IPv6 address based on an IPv6 general prefix and to enable IPv6 processing on an interface.

    Example:

    Router(config-if)# ipv6 add 2001:DB8::1:1/128

  2. Use the interface [type] [number] to specify the interface type and number.

    Example:

    Router(config-if)# interface Loopback4

  3. Use the ipv6 address [ipv6-address/prefix-length | prefix-name sub-bits /prefix-length ] to configure an IPv6 address based on an IPv6 general prefix and to enable IPv6 processing on an interface.

    Example:

    Router(config-if)# ipv6 address 2001:DB8::4:4/64

  4. Use the no shut to enable the interface.

    Example:

    Router(config-if)#  no shut

  5. Use the interface [type] [number] to specify the interface type and number.

    Example:

    Router(config-if)# interface Loopback5

  6. Use the ipv6 address vrf [vrf -name] rp-address [ipv6-address ] [group-address-list] [bidir] to configure the address of a PIM RP for a particular group range.

    Example:

    Router(config-if)# ipv6 pim rp-address 2001:DB8::1:1 acl_sparse1

  7. Use the no shut to enable the interface.

    Example:

    Router(config-if)# no shut

  8. Use the exit command to exit interface configuration mode and enter the global configuration mode.

    Example:

    Router(config-if)# exit

Step 2

Use these commands to configure the address of the PIM RP:

  1. Use the ipv6 pim anycast-RP [rp-address] [peer-address] to configure the address of the PIM RP for an anycast group range.

    Example:

    Router(config-if)# ipv6 pim anycast-rp 2001:DB8::1:1 2001:DB8::3:3

  2. Use the ipv6 pim anycast-RP [rp-address] [local-address] to configure the address of the PIM RP for an anycast group range.

    Example:

    Router(config-if)# ipv6 pim anycast-rp 2001:DB8::1:1 2001:DB8::4:4

Step 3

Configure RP2 using the given steps.

  1. Use the ipv6 address [ipv6-address/prefix-length | prefix-name sub-bits /prefix-length ] to configure an IPv6 address based on an IPv6 general prefix and to enable IPv6 processing on an interface.

    Example:

    Router(config-if)# ipv6 add 2001:DB8::1:1/128

  2. Use the interface [type] [number] to specify the interface type and number.

    Example:

    Router(config-if)# interface Loopback4

  3. Use the ipv6 address [ipv6-address/prefix-length | prefix-name sub-bits /prefix-length ] to configure an IPv6 address based on an IPv6 general prefix and to enable IPv6 processing on an interface.

    Example:

    Router(config-if)# ipv6 address 2001:DB8::3:3/64

  4. Use the no shut to enable the interface.

    Example:

    Router(config-if)# no shut

  5. Use the interface [type] [number] to specify the interface type and number.

    Example:

    Router(config-if)# interface Loopback5

  6. Use the ipv6 address vrf [vrf -name] rp-address [ipv6-address ] [group-address-list] [bidir] to configure the address of a PIM RP for a particular group range.

    Example:

    Router(config-if)# ipv6 pim rp-address 2001:DB8::1:1 acl_sparse1

  7. Use the no shut to enable the interface.

    Example:

    Router(config-if)# no shut

  8. Use the ipv6 pim anycast-RP [rp-address] [peer-address] to configure the address of the PIM RP for an anycast group range.

    Example:

    Router(config-if)# ipv6 pim anycast-rp 2001:DB8::1:1 2001:DB8::3:3

  9. Use the ipv6 pim anycast-RP [rp-address] [local-address] to configure the address of the PIM RP for an anycast group range.

    Example:

    Router(config-if)# ipv6 pim anycast-rp 2001:DB8::1:1 2001:DB8::4:4