About PIM and PIM6
PIM, which is used between multicast-capable routers, advertises group membership across a routing domain by constructing multicast distribution trees. PIM builds shared distribution trees on which packets from multiple sources are forwarded, as well as source distribution trees on which packets from a single source are forwarded.
Cisco NX-OS supports PIM sparse mode for IPv4 networks (PIM) and for IPv6 networks (PIM6). In PIM sparse mode, multicast traffic is sent only to locations of the network that specifically request it. You can configure PIM and PIM6 to run simultaneously on a router. You can use PIM and PIM6 global parameters to configure rendezvous points (RPs), message packet filtering, and statistics. You can use PIM and PIM6 interface parameters to enable multicast, identify PIM borders, set the PIM hello message interval, and set the designated router (DR) priority.
Note |
Cisco NX-OS does not support PIM dense mode. |
In Cisco NX-OS, multicast is enabled only after you enable the PIM and PIM6 feature on each router and then enable PIM or PIM6 sparse mode on each interface that you want to participate in multicast. You can configure PIM for an IPv4 network and PIM6 for an IPv6 network. In an IPv4 network, if you have not already enabled IGMP on the router, PIM enables it automatically. In an IPv6 network, MLD is enabled by default.
You use the PIM and PIM6 global configuration parameters to configure the range of multicast group addresses to be handled by these distribution modes:
-
Any Source Multicast (ASM) provides discovery of multicast sources. It builds a shared tree between sources and receivers of a multicast group and supports switching over to a source tree when a new receiver is added to a group. ASM mode requires that you configure an RP.
-
Source-Specific Multicast (SSM) builds a source tree originating at the designated router on the LAN segment that receives a request to join a multicast source. SSM mode does not require you to configure RPs. Source discovery must be accomplished through other means.
-
Bidirectional shared trees (Bidir) build a shared tree between sources and receivers of a multicast group but do not support switching over to a source tree when a new receiver is added to a group. Bidir mode requires that you configure an RP. Bidir forwarding does not require source discovery because only the shared tree is used.
Note
Cisco Nexus 9000 Series switches do not support PIM6 Bidir.
You can combine these modes to cover different ranges of group addresses.
For more information about PIM sparse mode and shared distribution trees used by the ASM and Bidir modes, see RFC 4601.
For more information about PIM SSM mode, see RFC 3569.
For more information about PIM Bidir mode, see draft-ietf-pim-bidir-09.txt.
PIM SSM with vPC
Beginning with Cisco NX-OS Release 7.0(3)I4(1), you can enable PIM SSM on Cisco Nexus 9000 Series switches with an upstream Layer 3 cloud along with the vPC feature.
A PIM adjacency between a Switched Virtual Interface (SVI) on a vPC VLAN (a VLAN that is carried on a vPC Peer-Link) and a downstream device is not supported; this configuration can result in dropped multicast packets. If a PIM neighbor relationship is required with a downstream device, a physical Layer 3 interface must be used on the Nexus switches instead of a vPC SVI.
For SVIs on vPC VLANs, only one PIM adjacency is supported, which is with the vPC peer switch. PIM adjacencies over the vPC peer-link with devices other than the vPC peer switch for the vPC-SVI are not supported.
Note |
Cisco Nexus 9508 switches with the N9K-X9636C-R and N9K-X9636Q-R line cards support PIM SSM beginning with Cisco NX-OS Release 7.0(3)F2(1) but do not support PIM SSM on vPCs until Cisco NX-OS Release 7.0(3)F3(1). The N9K-X9636C-RX line card supports PIM SSM with and without vPCs beginning with Cisco NX-OS Release 7.0(3)F3(1). |
PIM Flooding Mechanism and Source Discovery
Protocol Independent Multicast (PIM) flooding mechanism with Source Discovery (SD) (PFM-SD) eliminates the necessity for Rendezvous Points (RPs) while sending the multicast data streams. This technique is suitable for deployments that are concerned with switch over from shared tree to shorter path (*, G) tree delays.. This technique in PIM provides a way to support PIM-Sparse Mode (SM) without the need for PIM registers, RP, or shared trees. This technique is efficient and only creates (S,G) trees. Multicast source information can be propagated throughout the multicast domain using the PIM flooding mechanism. The PFM-SD mode can coexist with the Non-Blocking Multicast (NBM). For more information about PIM-SD mode, see RFC 8364.
Beginning with Cisco NX-OS Release 10.3(2)F, the PFM-SD feature is supported for IPv4 on Cisco Nexus 9000 Series, Nexus 9800 switches, and Cisco Nexus 9504/9508 switches with N9K-X9636C-R, N9K-X9636Q-R,N9K-X9636C-RX and N9K-X96136YC-R line cards.
Hello Messages
The PIM process begins when the router establishes PIM neighbor adjacencies by sending PIM hello messages to the multicast IPv4 address 224.0.0.13 or IPv6 address ff02::d. Hello messages are sent periodically at the interval of 30 seconds. When all neighbors have replied, the PIM software chooses the router with the highest priority in each LAN segment as the designated router (DR). The DR priority is based on a DR priority value in the PIM hello message. If the DR priority value is not supplied by all routers, or the priorities match, the highest IP address is used to elect the DR.
The hello message also contains a hold-time value, which is typically 3.5 times the hello interval. If this hold time expires without a subsequent hello message from its neighbor, the device detects a PIM failure on that link.
The configured hold-time changes may not take effect on first two hellos sent after enabling or disabling PIM on an interface. For the first two hellos sent on the interface, thereafter, the configured hold times will be used. This may cause the PIM neighbor to set the incorrect neighbor timeout value for the initial neighbor setup until a hello with the correct hold time is received.
For added security, you can configure an MD5 hash value that the PIM software uses to authenticate PIM hello messages with PIM neighbors.
Note |
PIM6 does not support MD5 authentication. |
Join-Prune Messages
When the DR receives an IGMP membership report message from a receiver for a new group or source, the DR creates a tree to connect the receiver to the source by sending a PIM join message out the interface toward the rendezvous point (ASM or Bidir mode) or source (SSM mode). The rendezvous point (RP) is the root of a shared tree, which is used by all sources and hosts in the PIM domain in the ASM or Bidir mode. SSM does not use an RP but builds a shortest path tree (SPT) that is the lowest cost path between the source and the receiver.
When the DR determines that the last host has left a group or source, it sends a PIM prune message to remove the path from the distribution tree.
The routers forward the join or prune action hop by hop up the multicast distribution tree to create (join) or tear down (prune) the path.
Note |
In this publication, the terms “PIM join message” and “PIM prune message” are used to simplify the action taken when referring to the PIM join-prune message with only a join or prune action. |
Join-prune messages are sent as quickly as possible by the software. You can filter the join-prune messages by defining a routing policy.
State Refreshes
PIM requires that multicast entries are refreshed within a 3.5-minute timeout interval. The state refresh ensures that traffic is delivered only to active listeners, and it keeps routers from using unnecessary resources.
To maintain the PIM state, the last-hop DR sends join-prune messages once per minute. State creation applies to both (*, G) and (S, G) states as follows:
-
(*, G) state creation example—An IGMP (*, G) report triggers the DR to send a (*, G) PIM join message toward the RP.
-
(S, G) state creation example—An IGMP (S, G) report triggers the DR to send an (S, G) PIM join message toward the source.
If the state is not refreshed, the PIM software tears down the distribution tree by removing the forwarding paths in the multicast outgoing interface list of the upstream routers.
Rendezvous Points
A rendezvous point (RP) is a router that you select in a multicast network domain that acts as a shared root for a multicast shared tree. You can configure as many RPs as you like, and you can configure them to cover different group ranges.
Static RP
You can statically configure an RP for a multicast group range. You must configure the address of the RP on every router in the domain.
You can define static RPs for the following reasons:
-
To configure routers with the Anycast-RP address
-
To manually configure an RP on a device
BSRs
The bootstrap router (BSR) ensures that all routers in the PIM domain have the same RP cache as the BSR. You can configure the BSR to help you select an RP set from BSR candidate RPs. The function of the BSR is to broadcast the RP set to all routers in the domain. You select one or more candidate BSRs to manage the RPs in the domain. Only one candidate BSR is elected as the BSR for the domain.
BSR is supported on Cisco Nexus 9300-EX/FX/FX2/FX3/GX/C and 9500-EX/FX/GX platform switches.
This figure shows the BSR mechanism. Router A, the software-elected BSR, sends BSR messages out all enabled interfaces (shown by the solid lines in the figure). The messages, which contain the RP set, are flooded hop by hop to all routers in the network. Routers B and C are candidate RPs that send their candidate-RP advertisements directly to the elected BSR (shown by the dashed lines in the figure).
The elected BSR receives candidate-RP messages from all the candidate RPs in the domain. The bootstrap message sent by the BSR includes information about all of the candidate RPs. Each router uses a common algorithm to select the same RP address for a given multicast group.
In the RP selection process, the RP address with the best priority is determined by the software. If the priorities match for two or more RP addresses, the software might use the RP hash in the selection process. Only one RP address is assigned to a group.
By default, routers are not enabled to listen or forward BSR messages. You must enable the BSR listening and forwarding feature so that the BSR mechanism can dynamically inform all routers in the PIM domain of the RP set assigned to multicast group ranges.
Note |
The BSR mechanism is a nonproprietary method of defining RPs that can be used with third-party routers. |
Note |
BSR is not supported for PIM6. |
Auto-RP
Auto-RP is a Cisco protocol that was introduced prior to the Internet standard bootstrap router mechanism. You configure Auto-RP by selecting candidate mapping agents and RPs. Candidate RPs send their supported group range in RP-Announce messages to the Cisco RP-Announce multicast group 224.0.1.39. An Auto-RP mapping agent listens for RP-Announce messages from candidate RPs and forms a Group-to-RP mapping table. The mapping agent multicasts the Group-to-RP mapping table in RP-Discovery messages to the Cisco RP-Discovery multicast group 224.0.1.40.
This figure shows the Auto-RP mechanism. Periodically, the RP mapping agent multicasts the RP information that it receives to the Cisco-RP-Discovery group 224.0.1.40 (shown by the solid lines in the figure).
By default, routers are not enabled to listen or forward Auto-RP messages. You must enable the Auto-RP listening and forwarding feature so that the Auto-RP mechanism can dynamically inform routers in the PIM domain of the group-to-RP mapping.
Note |
Auto-RP is not supported for PIM6. |
Caution |
Do not configure both Auto-RP and BSR protocols in the same network. |
Multiple RPs Configured in a PIM Domain
This section describes the election process rules when multiple RPs are configured in a PIM domain.
Anycast-RP
Anycast-RP has two implementations: one uses Multicast Source Discovery Protocol (MSDP) and the other is based on RFC 4610, Anycast-RP Using Protocol Independent Multicast (PIM). This section describes how to configure PIM Anycast-RP.
You can use PIM Anycast-RP to assign a group of routers, called the Anycast-RP set, to a single RP address that is configured on multiple routers. The set of routers that you configure as Anycast-RPs is called the Anycast-RP set. This method is the only RP method that supports more than one RP per multicast group, which allows you to load balance across all RPs in the set. The Anycast RP supports all multicast groups.
PIM register messages are sent to the closest RP, and PIM join-prune messages are sent in the direction of the closest RP as determined by the unicast routing protocols. If one of the RPs goes down, unicast routing ensures these messages will be sent in the direction of the next-closest RP.
You must configure PIM on the loopback interface that is used for the PIM Anycast RP and the PIM Bidir RP.
For more information about PIM Anycast-RP, see RFC 4610.
PIM Register Messages
PIM register messages are unicast to the RP by designated routers (DRs) that are directly connected to multicast sources. The PIM register message has the following functions:
-
To notify the RP that a source is actively sending to a multicast group.
-
To deliver multicast packets sent by the source to the RP for delivery down the shared tree.
The DR continues to send PIM register messages to the RP until it receives a Register-Stop message from the RP. The RP sends a Register-Stop message in either of the following cases:
-
The RP has no receivers for the multicast group being transmitted.
-
The RP has joined the SPT to the source but has not started receiving traffic from the source.
The PIM triggered register is enabled by default.
You can use the ip pim register-source command to configure the IP source address of register messages when the IP source address of a register message is not a uniquely routed address to which the RP can send packets. This situation might occur if the source address is filtered so that the packets sent to it are not forwarded or if the source address is not unique to the network. In these cases, the replies sent from the RP to the source address will fail to reach the DR, resulting in Protocol Independent Multicast sparse mode (PIM-SM) protocol failures.
The following example shows how to configure the IP source address of the register message to the loopback 3 interface of a DR:
ip pim register-source loopback 3
Note |
In Cisco NX-OS, PIM register messages are rate limited to avoid overwhelming the RP. |
You can filter PIM register messages by defining a routing policy.
Designated Routers
In PIM ASM and SSM modes, the software chooses a designated router (DR) from the routers on each network segment. The DR is responsible for forwarding multicast data for specified groups and sources on that segment.
The DR for each LAN segment is determined as described in the Hello messages.
In ASM mode, the DR is responsible for unicasting PIM register packets to the RP. When a DR receives an IGMP membership report from a directly connected receiver, the shortest path is formed to the RP, which may or may not go through the DR. The result is a shared tree that connects all sources transmitting on the same multicast group to all receivers of that group.
In SSM mode, the DR triggers (S, G) PIM join or prune messages toward the source. The path from the receiver to the source is determined hop by hop. The source must be known to the receiver or the DR.
Designated Forwarders
In PIM Bidir mode, the software chooses a designated forwarder (DF) at RP discovery time from the routers on each network segment. The DF is responsible for forwarding multicast data for specified groups on that segment. The DF is elected based on the best metric from the network segment to the RP.
If the router receives a packet on the RPF interface toward the RP, the router forwards the packet out all interfaces in the OIF-list. If a router receives a packet on an interface on which the router is the elected DF for that LAN segment, the packet is forwarded out all interfaces in the OIF-list except the interface that it was received on and also out the RPF interface toward the RP.
Note |
Cisco NX-OS puts the RPF interface into the OIF-list of the MRIB but not in the OIF-list of the MFIB. |
ASM Switchover from Shared Tree to Source Tree
Note |
Cisco NX-OS puts the RPF interface into the OIF-list of the MRIB but not into the OIF-list of the MFIB. |
In ASM mode, the DR that is connected to a receiver switches over from the shared tree to the shortest-path tree (SPT) to a source unless you configure the PIM parameter to use shared trees only.
During the switchover, messages on the SPT and shared tree might overlap. These messages are different. The shared tree messages are propagated upstream toward the RP, while SPT messages go toward the source.
For information about SPT switchovers, see the “Last-Hop Switchover to the SPT" section in RFC 4601.
Multicast Flow Path Visibility for TRM Flows
Beginning with Cisco NX-OS Release 10.2(1)F, Multicast Flow Path Visualization (FPV) for TRM Flows feature is supported for TRM L3 mode and underlay multicast along with the already supported multicast flowsis supported. This feature enables you to export all multicast states in a Cisco Nexus 9000 Series switch. This helps to have a complete and reliable traceability of the flow path from the source to a receiver.
To enable Multicast Flow Path Data Export on Cisco Nexus 9000 Series switches, use the multicast flow-path export command.
This feature supports the following:
-
Flow Path Visualization (FPV).
-
Export flow statistics and states for failure detection.
-
Root cause analysis on the switches along the flow path. This is done by running the appropriate debug commands.
Administratively Scoped IP Multicast
The administratively scoped IP multicast method allows you to set boundaries on the delivery of multicast data. For more information, see RFC 2365.
You can configure an interface as a PIM boundary so that PIM messages are not sent out on that interface.
You can use the Auto-RP scope parameter to set a time-to-live (TTL) value.
Multicast Counters
-
Enable multicast heavy template as described in the Enabling the Multicast Heavy Template section.
-
Configure the hardware profile multicast flex-stats-enable command in the default template.
Only Cisco Nexus 9300-EX, X9700-FX, 9300-FX, and 9300-FX2 Series switches support multicast counters. These counters provide more granularity and visibility about multicast traffic. Specifically, they show an absolute multicast packet count (bytes and rate for every multicast S,G route). These counters are valid only for S,G routes and not for *,G routes. Multicast counters appear in the output of the show ip mroute detail and show ip mroute summary commands when the multicast heavy template is enabled.
Multicast Heavy Template
You can enable the multicast heavy template in order to support significantly more multicast routes and to display multicast counters in the output of the show ip mroute command.
The multicast heavy template is supported for the following devices and releases:
-
Cisco Nexus N9K-X9732C-EX, N9K-X9736C-E, and N9K-X97160YC-EX line cards, beginning with Cisco NX-OS Release 7.0(3)I3(2), but only for increased scalability
-
Cisco Nexus 9300-EX Series switches, beginning with Cisco NX-OS Release 7.0(3)I6(1), for both increased scalability and multicast counters
-
Cisco Nexus 9300-FX Series switches, beginning with Cisco NX-OS Release 7.0(3)I7(1), for both increased scalability and multicast counters
Multicast VRF-Lite Route Leaking
Beginning with Cisco NX-OS Release 7.0(3)I7(1), multicast receivers can forward IPv4 traffic across VRFs. In previous releases, multicast traffic can flow only within the same VRF.
With multicast VRF-lite route leaking, Reverse Path Forwarding (RPF) lookup for multicast routes in the receiver VRF can be performed in the source VRF. Therefore, traffic originating from the source VRF can be forwarded to the receiver VRF.
PIM Graceful Restart
Protocol Independent Multicast (PIM) graceful restart is a multicast high availability (HA) enhancement that improves the convergence of multicast routes (mroutes) after a route processor (RP) switchover. In the event of an RP switchover, the PIM graceful restart feature utilizes the generation ID (GenID) value (defined in RFC 4601) as a mechanism to trigger adjacent PIM neighbors on an interface to send PIM join messages for all (*, G) and (S, G) states that use that interface as a reverse path forwarding (RPF) interface. This mechanism enables PIM neighbors to immediately reestablish those states on the newly active RP.
Generation IDs
A generation ID (GenID) is a randomly generated 32-bit value that is regenerated each time Protocol Independent Multicast (PIM) forwarding is started or restarted on an interface. In order to process the GenID value in PIM hello messages, PIM neighbors must be running Cisco software with an implementation of PIM that is compliant with RFC 4601.
Note |
PIM neighbors that are not compliant with RFC 4601 and are unable to process GenID differences in PIM hello messages will ignore the GenIDs. |
PIM Graceful Restart Operations
This figure illustrates the operations that occur after a route processor (RP) switchover on devices that support the PIM graceful restart feature.
The PIM graceful restart operations are as follows:
-
In steady state, PIM neighbors exchange periodic PIM hello messages.
-
An active RP receives PIM joins periodically to refresh multicast route (mroute) states.
-
When an active RP fails, the standby RP takes over to become the new active RP.
-
The new active RP then modifies the generation ID (GenID) value and sends the new GenID in PIM hello messages to adjacent PIM neighbors.
-
Adjacent PIM neighbors that receive PIM hello messages on an interface with a new GenID send PIM graceful restart for all (*, G) and (S, G) mroutes that use that interface as an RPF interface.
-
Those mroute states are then immediately reestablished on the newly active RP.
PIM Graceful Restart and Multicast Traffic Flow
Multicast traffic flow on PIM neighbors is not affected if the multicast traffic detects support for PIM graceful restart PIM or PIM hello messages from a node with the failing RP within the default PIM hello hold-time interval. Multicast traffic flow on a failing RP is not affected if it is non-stop forwarding (NSF) capable.
Caution |
The default PIM hello hold-time interval is 3.5 times the PIM hello period. Multicast high availability (HA) operations might not function as per design if you configure the PIM hello interval with a value lower than the default value of 30 seconds. |
High Availability
When a route processor reloads, multicast traffic across VRFs behaves the same as traffic forwarded within the same VRF.
For information about high availability, see the Cisco Nexus 9000 Series NX-OS High Availability and Redundancy Guide.