If multiple multicast routers share a single segment, all of them could flood this segment with the same multicast traffic. To avoid this situation, only one router is allowed to flood traffic on the shared segment. When a router detects that someone is sending traffic for the same source IP/destination group on the segment, where it has an active (S,G) state for the same group/source, it immediately originates a PIM Assert message. This message contains the source IP, the group, and the path cost to the source. The path cost is a touple (AD, Metric), where AD is the administrative distance of the routing protocol used to look up the source IP, and Metric is that same protocol’s metric to reach the source. The router with the best (lowest) AD value on the segment wins the assertion. If the ADs are equal, metric is used as tie-breaker. If both the AD and the metric are the same, the router with the highest IP address wins. If another router on the segment receives the Assert message and determines that it loses the assertion, it will remove the (S,G) state on its interface and stop flooding traffic. However, if it sees itself as the winner, it will emit a superior PIM Assert message to inform the other router that it should stop flooding the traffic for this (S,G) pair.

Note that the PIM Assert procedure might be dangerous on NBMA interfaces. PIM will treat those interfaces as fully broadcast capable networks, even though not all nodes are capable of hearing each-other’s broadcast messages. Imagine a hub-and- spoke DMVPN topology. If both the hub and the spoke start flooding the segment with the same multicast traffic, PIM Assert will occur. If for some reason the spoke should win, the hub will stop sending its multicast traffic. However, all traffic coming from the spoke to the hub is NOT relayed back to the other spokes sharing the same segment, based on the RPF rule. Thus, all other spokes will effectively stop receiving the multicast traffic. To avoid this situation, either use PIM NBMA mode (described in a separate task) or make sure that the hub always wins the PIM Assert procedure. PIM NBMA mode, however, is supported only in PIM Sparse Mode.

From a configuration side, you have to know the above to be able to influence the Assert decision process. For example, you could use an mroute statement to affect the administrative distance from a particular router, causing it to win the Assert election.

What happens if the Assert Winner stops working? Unfortunately, the Assert “Loser” has no way of knowing that the Assert “Winner” has failed and will wait three (3) minutes before timing out its pruned interface. Thus, we face a worst case scenario of loss of traffic for three minutes should the PIM Assert winner go down right after winning the election.