Filter
Top Products
Nokia Network Voyager for IPSO 4.0 Reference Guide 371
For Sparse-Mode PIM, see Protocol-Independent Multicast—Sparse Mode (PIM-SM): Protocol
Specification (Revised).
Configuring Virtual IP Support for VRRP
The virtual IP option lets you configure either a PIM sparse-mode or PIM dense-mode interface
to advertise the VRRP virtual IP address if the router transitions to become VRRP master after a
failover. When you enable virtual IP support for VRRP on a PIM interface, it establishes the
neighbor relationship by using the virtual IP if the router is a VRRP master. The master in the
VRRP pair sends hello messages that include the virtual IP as the source address and processes
PIM control messages from routers that neighbor the VRRP pair. For more information on how
to configure this option through Network Voyager, see either “Configuring Dense-Mode PIM”
or “Configuring Sparse-Mode PIM.”
Note
You must use monitored-circuit VRRP when configuring virtual IP support for any dynamic
routing protocol, including PIM. Do not use VRRPv2 when configuring virtual IP support for
any dynamic routing protocol.
PIM Support for IP Clustering
Beginning with IPSO 3.8.1, Nokia supports PIM, both Dense-Mode and Sparse-Mode, in a
cluster. Nokia also supports IGMP in a cluster.
IPSO clusters have three modes of operation. To use PIM, either Dense-Mode or Sparse-Mode,
in an IP cluster, you must use either multicast mode or multicast mode with IGMP as the cluster
mode. Do not use forwarding mode. For more information about IP clustering, see “IP
Clustering Description” on page 207
Note
Nokia strongly recommends that you not configure PIM or any other routing protocol on the
primary or secondary cluster protocol interfaces of an IP cluster.
PIM Dense-Mode
In the Nokia implementation of PIM Dense-Mode (PIM-DM), all the nodes process PIM control
traffic received by the cluster, and only the master processes most of the control traffic sent from
the cluster. However, hello messages, for example, are sent by all nodes. Some multicast
switches do not forward multicast traffic to interfaces from which they have not received any
multicast traffic. To avoid having a multicast switch fail to forward multicast traffic, all cluster
nodes send periodic PIM hello messages. All messages from each cluster member have the same
source IP address, generation ID, holdtime and designated router priority. Therefore, all
neighboring routers view the cluster as a single neighbor even though they receive hello
messages from all members of the cluster.