How to Implement a Filtering Policy for Rendezvous Points

Available Languages

Download Options

PDF (130.4 KB)
View with Adobe Reader on a variety of devices
ePub (76.7 KB)
View in various apps on iPhone, iPad, Android, Sony Reader, or Windows Phone
Mobi (Kindle) (72.9 KB)
View on Kindle device or Kindle app on multiple devices

Updated:April 4, 2006

Document ID:41680

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Introduction

Prerequisites

Requirements

Components Used

Conventions

Auto-RP

Filtering RP Addresses

Filtering Example

Verify

Troubleshoot

Related Information

Introduction

This document explains how to implement a filtering policy for rendezvous points (RPs) at the RP mapping agent in a multicast environment where a dynamic RP configuration is applied (Auto-RP).

Prerequisites

Requirements

Ensure that you meet these requirements before you attempt this configuration:

Basic understanding of Protocol Independent Multicast (PIM)

Components Used

Use this diagram as a reference throughout this document:

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to Cisco Technical Tips Conventions for more information on document conventions.

Auto-RP

Auto-RP is a dynamic way to learn the RP information for every router in the network. This is achieved when you distribute all the group-to-RP information via IP multicast.

All PIM-enabled routers automatically join the Cisco RP discovery group (224.0.1.40) which allows them to receive all group-to-RP mapping information. This information is distributed by an entity called RP mapping agent. Mapping agents themselves join another group—the Cisco RP announce group (224.0.1.39). All candidate RPs advertise themselves in periodic multicast messages aimed at the RP announce group address.

The mapping agent listens to all RP candidate announcements and builds a table with the information. If several RPs announce themselves for a multicast group range, the mapping agent chooses only one—the RP with the highest IP address. It then advertises the RP to all PIM routers in the network using an RP discovery message. Mapping agents send this information every 60 seconds (the default setting).

Filtering RP Addresses

You can use the ip pim rp-announce-filter rp-list access-list group-list access-list command to filter certain RPs for certain multicast groups.

The ip pim rp-announce-filter rp-list access-list group-list access-list command only has meaning if it is configured at the mapping agent. The rp-list access-list defines an access-list of candidate RPs that, if permitted, are accepted for the multicast ranges specified in the group-list access-list command.

Note: Use this command with caution. RPs that are matched by rp-list (allowed by a permit statement) have their multicast groups filtered by group-list. RPs that are denied (either by an explicit or implicit deny) are not subject to the filtering of their multicast groups and are "blindly" accepted as candidate RPs for all of their groups. In other words, only RPs that are permitted by rp-list have their multicast-groups filtered by group-list. All other RPs are accepted without examination.

An additional RP announce filter is needed to effectively filter the RPs that are accepted without examination. The Filtering Example section clarifies this procedure.

Filtering Example

In the diagram in the Components Used section, R2 and R4 announce themselves as candidate RPs for these groups (which advertise this information via RP discovery messages):

224.1.0.1
224.1.0.2
224.1.0.3

R3 is configured as a mapping agent and gathers this information, builds its table, and sends only one RP address to R6, which is only a PIM-enabled router. Intermediate System-to-Intermediate System (IS-IS) is used in this example as the unicast routing protocol, but any other protocol would work as well. PIM sparseDense mode is needed to receive multicast information for groups 224.0.1.39 and 224.0.1.40 without having an RP configured for those groups. In other words, sparseDense mode works like dense mode if there is no known RP. When an RP is known, sparseDense mode is used for the groups for which the RP advertises itself.

R2 Configuration

hostname R2

ip multicast-routing

interface Loopback0
 ip address 50.0.0.2 255.255.255.255
 ip router isis
 ip pim sparse-dense mode

interface Serial3/0
 ip address 10.2.0.2 255.255.255.0
 ip router isis
 ip pim sparse-dense mode

router isis 
 net 49.0002.0000.0000.0002.00

ip pim send-rp-announce Loopback0 scope 16 group-list groupB
!         
!         
ip access-list standard groupB
 permit 224.1.0.1
 permit 224.1.0.2
 permit 224.1.0.3

R4 Configuration

hostname R4

ip multicast-routing

interface Loopback0
 ip address 50.0.0.4 255.255.255.255
 ip router isis
 ip pim sparse-dense mode

interface Serial3/0
 ip address 10.3.0.4 255.255.255.0
 ip router isis
 ip pim sparse-dense mode

router isis 
 net 49.0002.0000.0000.0004.00

ip pim send-rp-announce Loopback0 scope 16 group-list groupA
!         
!         
ip access-list standard groupA
 permit 224.1.0.1
 permit 224.1.0.2
 permit 224.1.0.3

R3 Configuration

hostname R3

ip multicast-routing

interface Loopback0
 ip address 50.0.0.3 255.255.255.255
 ip router isis
 ip pim sparse-dense mode

interface Ethernet1/0.1
 encapsulation dot1Q 65
 ip address 65.0.0.3 255.255.255.0
 ip router isis 
 ip pim sparse-dense-mode

interface Serial2/0
 ip address 10.2.0.3 255.255.255.0
 ip router isis 
 ip pim sparse-dense-mode

interface Serial3/0
 ip address 10.3.0.3 255.255.255.0
 ip router isis 
 ip pim sparse-dense-mode

router isis 
 net 49.0002.0000.0000.0003.00

R6 Configuration

hostname R6

ip multicast-routing

interface Loopback0
 ip address 50.0.0.6 255.255.255.255
 ip router isis
 
interface Ethernet1/0.1
 encapsulation dot1Q 65
 ip address 65.0.0.6 255.255.255.0
 ip router isis 
 ip pim sparse-dense-mode

router isis 
 net 49.0002.0000.0000.0006.00

If you want to filter R4 as a possible RP for any of those groups and only have R2 as a working RP, configure an RP announce filter in R3:

ip pim rp-announce-filter rp-list filtering-RP group-list filtering-group
!         
!         
ip access-list standard filtering-RP
 permit 50.0.0.2
 deny    50.0.0.4


!--- ACL "filtering-RP" specifically allows R2 and explicitly denies R4.


ip access-list standard filtering-group
 permit 224.1.0.1
 permit 224.1.0.2
 permit 224.1.0.3

Then, to clear the current group-to-RP associations, issue the clear ip pim rp-mapping command at both R3 and R6.

However, if you view R6, you can see that the information is not what you expect:

R6#show ip pim rp mapping 
PIM Group-to-RP Mappings

Group(s) 224.1.0.1/32
  RP 50.0.0.4 (?), v2v1

!--- RP is R4

    Info source: 65.0.0.3 (?), elected via Auto-RP
         Uptime: 00:00:02, expires: 00:02:55
Group(s) 224.1.0.2/32
  RP 50.0.0.4 (?), v2v1

!--- RP is R4

    Info source: 65.0.0.3 (?), elected via Auto-RP
         Uptime: 00:00:02, expires: 00:02:55
Group(s) 224.1.0.3/32
  RP 50.0.0.4 (?), v2v1

!--- RP is R4

    Info source: 65.0.0.3 (?), elected via Auto-RP
         Uptime: 00:00:02, expires: 00:02:55

If you view R3, you can see that no filtering is actually being performed:

R3# show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP-mapping agent

!--- This line confirms that R3 is configured as the mapping agent.


Group(s) 224.1.0.1/32
  RP 50.0.0.4 (?), v2v1

!--- No filtering has taken effect.

    Info source: 50.0.0.4 (?), elected via Auto-RP

!--- R4 is elected because it has a higher IP address.

         Uptime: 00:09:06, expires: 00:02:53
  RP 50.0.0.2 (?), v2v1
    Info source: 50.0.0.2 (?), via Auto-RP
         Uptime: 00:09:29, expires: 00:02:27
Group(s) 224.1.0.2/32
  RP 50.0.0.4 (?), v2v1
    Info source: 50.0.0.4 (?), elected via Auto-RP
         Uptime: 00:09:06, expires: 00:02:51
  RP 50.0.0.2 (?), v2v1
    Info source: 50.0.0.2 (?), via Auto-RP
         Uptime: 00:09:29, expires: 00:02:27
Group(s) 224.1.0.3/32
  RP 50.0.0.4 (?), v2v1
    Info source: 50.0.0.4 (?), elected via Auto-RP
         Uptime: 00:09:06, expires: 00:02:51
  RP 50.0.0.2 (?), v2v1
    Info source: 50.0.0.2 (?), via Auto-RP
         Uptime: 00:09:29, expires: 00:02:28

The address of R4 is specifically denied, and is not subject to any filtering of its multicast groups—it is "blindly" accepted by the mapping agent. The mapping agent selects one RP based on the highest IP address (in this example, 50.0.0.4) and then forwards this information to R6.

Configure another RP announce filter that permits R4 and denies all of its groups in order to effectively filter the R4 address:

ip pim rp-announce-filter rp-list filtering-R4 group-list filtering-groupR4

ip access-list standard filtering-R4
 permit 50.0.0.4
ip access-list standard filtering-groupR4
 deny   any

If you view R3 and enable the debug ip pim auto-rp command as soon as you receive an RP announce message from R4, you can see these messages:

R3#
*Apr 30 09:09:06.651: Auto-RP(0): Received RP-announce, from 50.0.0.4, RP_cnt 1, ht 181
*Apr 30 09:09:06.651: Auto-RP(0): Filtered 224.1.0.1/32 for RP 50.0.0.4
*Apr 30 09:09:06.651: Auto-RP(0): Filtered 224.1.0.3/32 for RP 50.0.0.4
*Apr 30 09:09:06.651: Auto-RP(0): Filtered 224.1.0.2/32 for RP 50.0.0.4
*Apr 30 09:09:06.651: Auto-RP(0): Received RP-announce, from 50.0.0.4, RP_cnt 1, ht 181
*Apr 30 09:09:06.651: Auto-RP(0): Filtered 224.1.0.1/32 for RP 50.0.0.4
*Apr 30 09:09:06.651: Auto-RP(0): Filtered 224.1.0.3/32 for RP 50.0.0.4
*Apr 30 09:09:06.651: Auto-RP(0): Filtered 224.1.0.2/32 for RP 50.0.0.4

Then, when you view the group-to-RP table, you can only see R2:

R3#show ip pim rp mapping 
PIM Group-to-RP Mappings
This system is an RP-mapping agent

Group(s) 224.1.0.1/32
  RP 50.0.0.2 (?), v2v1
    Info source: 50.0.0.2 (?), elected via Auto-RP
         Uptime: 00:00:04, expires: 00:02:52
Group(s) 224.1.0.2/32
  RP 50.0.0.2 (?), v2v1
    Info source: 50.0.0.2 (?), elected via Auto-RP
         Uptime: 00:00:04, expires: 00:02:54
Group(s) 224.1.0.3/32
  RP 50.0.0.2 (?), v2v1
    Info source: 50.0.0.2 (?), elected via Auto-RP
         Uptime: 00:00:04, expires: 00:02:55

Finally, if you want to have R2 as the RP for 224.1.0.1, and R4 as the RP for 224.1.0.2 and 224.1.0.3, you have this configuration at R3:

hostname R3

ip multicast-routing

interface Loopback0
 ip address 50.0.0.3 255.255.255.255
 ip router isis
 ip pim sparse-dense mode

interface Ethernet1/0.1
 encapsulation dot1Q 65
 ip address 65.0.0.3 255.255.255.0
 ip router isis
 ip pim sparse-dense-mode

interface Serial2/0
 ip address 10.2.0.3 255.255.255.0
 ip router isis
 ip pim sparse-dense-mode

interface Serial3/0
 ip address 10.3.0.3 255.255.255.0
 ip router isis
 ip pim sparse-dense-mode

router isis
 net 49.0002.0000.0000.0003.00

ip pim rp-announce-filter rp-list filtering-RP2 group-list filtering-group2
ip pim rp-announce-filter rp-list filtering-RP4 group-list filtering-group4
!        
!        
ip access-list standard filtering-RP2
 permit 50.0.0.2

ip access-list standard filtering-RP4
 permit 50.0.0.4

ip access-list standard filtering-group2
 permit 224.1.0.1

ip access-list standard filtering-group4
 permit 224.1.0.2
 permit 224.1.0.3

Revision History

Revision	Publish Date	Comments
1.0	04-Apr-2006	Initial Release

How to Implement a Filtering Policy for Rendezvous Points

Available Languages

Download Options

Bias-Free Language

Contents

Revision History

Was this Document Helpful?

Contact Cisco

This Document Applies to These Products