Specifying A Static Rp For A Specific Group - HP 7102dl - ProCurve Secure Router Configuration Manual

Configuring Multicast Support with PIM-SM
Configuring PIM-SM
N o t e
13-32

Specifying a Static RP for a Specific Group

Instead of configuring the same routers to support all multicast groups, you
can associate specific RPs with specific groups.
You should only use this option if your organization has a particular reason
for doing so. Usually, since routers immediately switch to an SP tree, the
location of the RP is not as important as it may seem.
However, if you force routers to use the RP tree permanently, the location of
the RP in the network topology becomes more important. In this case, config-
uring a hub router in the area in which you expect certain groups to be active
to be RP for those groups may significantly reduce the bandwidth consumed
by multicasts.
You can configure multiple RPs for the domain. Each RP can support a single
multicast group or a range of groups.
You can overlap address ranges, but doing so can lead to unexpected results.
For example, you can configure Router A to support 232.0.0.0 /5 and Router
B to support 239.255.255.1 /32. Both routers would then support the multicast
group, 239.255.255.1. Router B would not necessarily become the RP for the
single group that it supports. You should disable Router A from supporting
239.255.255.1 with a deny statement in the ACL associated with it.
When configuring a static RP set, you should keep these tips in mind:
At least one RP should be able to support every multicast group. Other-
wise, routers may not be able to route necessary multicasts. For example,
routers running various networking protocols multicast messages to
addresses between 224.0.0.0 and 224.0.0.255.
You should particularly avoid leaving the 224.0.0.0 to 224.0.0.255 range
without RP support: doing so poses the risk of disabling one or more
protocols needed in the network.
When you attempt to configure static RPs to support ranges of addresses
of varying lengths or to configure some RPs to support ranges and others
to support a single group, you open room for misconfigurations. You may
unintentionally leave a necessary multicast group without an RP to sup-
port it.
If you expect hosts throughout the PIM domain to join roughly the same
groups, you should consider allowing all RPs to support all groups. You
could alternatively split the range of multicast groups evenly among the
routers you want to act as RPs. However, this opens the possibility for a
group being left without support if a router fails.