PIM-BiDir
Load multicast.init.cfg
Configure CSR9 as the RP for 239.1.1.0/24 and XR4 as the RP for 239.2.2.0/24. Advertise the RP mapping using BSR. Use BiDir for these groups.
Answer
Explanation
BiDir is essentially an extension to PIM-SM. The RPT built from the receivers to the RP works exactly the same way. However, the PIM Register process is gone. Instead, multicast traffic is allowed to flow up the shared tree towards the RP. In order for this to work, the RPF check needs to be removed. A different loop prevent mechanism needs to be deployed. PIM-BiDir uses a spanning tree to enforce a loop free topology. You can think of this just as how classic STP works.
In PIM-BiDir, the “root port” is the BiDir Upstream port, which is the RPF interface towards the RP. The “Designated Ports” are elected via the DF (Designated Forwarder) election. This is a special PIM packet that each router originates on every link for every BiDir RP. A DF port is selected per-RP. Only one router can be elected DF on a given segment. The router with the best metric, or highest interface IP address is elected. The DF election PIM packet looks as follows:
Any ports that are not elected as DF on a router are placed into “blocking.” This is how a loop free topology is implemented in PIM-BiDir.
The benefit of PIM-BiDir is that there is no (S, G) state. This provides scalability when you have lots of senders and receivers. PIM-BiDir is suitable for multicast traffic such as video conferencing, in which every receiver is also a sender. All traffic is forwarded via the blanket (*, G) PIM-BiDir entry.
The downside to PIM-BiDir is that the RP must be 100% in the traffic flow. You should place the RP in a central location, because traffic will never switchover to a (S, G) entry in PIM-BiDir.
To enable PIM-BiDir on IOS-XE we need an explicit global statement. This is not required on IOS-XR; PIM-BiDir is already enabled by default.
The RP also must be associated with BiDir mode. This can be done statically, using AutoRP or using BSR. In this lab we use BSR.
At this point, we should see that all routers in the domain learn of the two RPs and the groups they are acting as RP for. We should also see that they are associated with BiDir mode.
On IOS-XR we can confirm that these two ranges are operating in BiDir mode:
The router learns that these ranges are BiDir, because there is a BiDir flag on the group range in the BSR message:
Next, the DF election takes place on every segment to enforce the strict loop free topology. Let’s “zoom in” on the election between R7-XR1-XR4, because this has a potential for a loop.
Let’s look at the DF election for R9 as the RP. R7 identifies its interface towards XR4 as the best path to R9, so this is the BiDir upstream port (or “root port” in STP terms) - marked as U. R7 and XR4 share their route AD/metric towards R9 with each other, and XR4 wins the DF election - marked as DF. So far our topology looks like this:
Next, R7 and XR1 run the DF election process. XR1 and R7 both have a 110/3 (AD/metric) route towards R9, so XR1 wins for higher IP address. XR1’s BiDir upstream interface is the interface towards XR4. On the XR1-XR4 interface, XR4 wins the election, with a metric of 110/2 towards R9. Since R7’s interface towards XR1 is neither a upstream interface, nor DF, R7 is effectively “blocking” on this port. We now have enforced a loop free topology.
We can see the results of the DF election using the following commands:
To actually enforce the results of the DF election, and therefore achieve a loop free topology, only certain interfaces are added to the (*, G) entry for the BiDir groups. For example, let’s look at (*, 239.1.1.0/24) on R7:
Above, the BiDir upstream is the interface towards XR4, as we identified previously. This is essentially an outgoing interface, as well as an incoming interface. Additionally, all ports for which the router is DF are added to the incoming interface list. A multicast packet arrive on this incoming interface is sent out the BiDir-upstream interface towards the RP. Notice that the interface towards XR1 is not present here. The loop free topology is enforced by only adding the upstream and DF ports to the incoming interface list. Traffic is not accepted on non-DF ports.
We can also see this on XR1. All of its interfaces are either DF or upstream ports, so all are present in the incoming interface list. Only the BiDir-upstream port is present in the outgoing interface list:
Let’s examine what happens when we start sending multicast traffic. R1 pings 239.1.1.1:
R7 accepts the traffic as it arrives on an incoming interface in the (*, 239.1.1.0/24) entry, and R7 forwards to XR4. R7 does not add a (S, G) entry for this. XR4 does the same, and forwards towards R9. R9 finds no interested receivers for (*, 239.1.1.1) so R9 drops the traffic. We can see this in a pcap. The ping is seen taking three hops: R1-R7, R7-XR4, XR4-R9:
This is another downside of PIM-BiDiR - there is no PIM Register Stop. So R9 cannot let a FHR know that it has no interested receivers. Instead, this traffic will use up unnecessary bandwidth in the network. It will always be sent all the way to the RP, and then dropped at the RP.
Let’s now join a receiver, using R2. R2 must run PIM-BiDir mode as well. It will automatically learn of the RPs via BSR too. Without using BiDir mode, R5 will sense that R2 is not running BiDir. R5 notices the lack of the BiDir capability flag set in the PIM Hello. R5 will not forward traffic to R2 even though it receives an IGMP join from R2. This is because R5 sees that R2 is a PIM neighbor but it is not participating in the DF election, so R5 must err on the side of caution in order to not form a loop. Keep in mind this is all done just to see an ICMP reply from R2. You could alternatively just watch the mfib counters on R5 and not run PIM on R2 at all.
On R5, we see that a (*, G) state was created. The interface that R5 received the IGMP report on is added to the OIL. The RPF interface is inherited from the (*, 239.1.1.0/24) entry and is both an IIF and outgoing interface.
A PIM Join makes its way to R9. This is the exact same process as in regular PIM-SM.
In PIM-BiDir, (*, G) state only exists on the shared tree between the RP and receivers as in normal PIM-SM. Traffic is forwarded from sources only based on a blanket (*, G) entry such as (*, 239.1.1.0/24).
R1 pings 239.1.1.1 and receives a reply from R2:
On routers between the sender and the RP, there is no (S, 239.1.1.1) or even (*, 239.1.1.1) state. All traffic is forwarded via the (*, 239.1.1.0/24) entry:
On routers between the RP and the receiver, the (*, G) state is present due to the PIM Join process.
This is what makes PIM-BiDir scalable: all traffic is forwarded based on (*, G/32) or (*, G/X) entries. (S, G) entries are never created.
Let’s briefly look at XR as the LHR. We’ll join the same group on R4.
We’ll now look at the MRIB on XR3. The IA flag means “inherit accept,” so the (*, G) entry inherits all the acceptance interfaces found in the blanket (*, G/X) entry. The interface towards R4 is added to the OIL for the specific (*, G) entry.
In many ways, PIM-BiDir is actually more simple than PIM-SM. There is no PIM Register or Register stop process, there is no (S, G) tree the RP must join, and there is no SPT switchover process. The complexity just comes from the loop free topology enforcement, which uses a DF election process and ensures that no non-DF/upstream interfaces are added to the incoming interface list.
Let’s also test the reverse direction. We’ll set R1 to join 239.1.1.1.
R9 now has three interfaces added to the OIL. One interface towards each receiver.
When R2 pings 239.1.1.1, we see a reply from R1, R2 (itself) and R4:
What happens if a router in the path does not have BiDir enabled?
Let’s disable BiDir on R10:
R10 shows us that it still learns of the RPs and that they are in BiDir mode, but warns us that BiDir is disabled locally.
R10 still has the mroute states, but these are not functioning correctly. R10 can only add its own BiDir upstream to the incoming interface list, because it is not running DF election on its interfaces.
Additionally, R5 cannot send a PIM Join towards R10 for the (*, 239.1.1.1) entry. This appears to be because R5 knows that R10 is not BiDir capable, so it will not use its as the RPF neighbor. Strangely, R5 does still use R10 as the RPF neighbor for the /24 entries.
Traffic can flow neither down or up the shared tree.
What if R10 enables PIM-BiDir but treats the group as non-BiDir?
What if R10 does enable PIM-BiDir but it treats 239.1.1.0/24 as non-BiDir? Let’s test this out by removing BSR in our network so we can define the RP statically on each router.
After the RP information cached from BSR times out, we should be left with only a single static RP mapping on all routers.
On R10 we’ll now set the RP as non-bidir mode:
The same symptoms appear. R5 sees that R10 is not participating in a DF election for RP 1.0.0.9. So R5 does not use R10 as the RPF neighbor for its (*, 239.1.1.1) entry. Therefore traffic downstream from the RP does not get delivered to R2. Additionally, traffic cannot travel upstream through R10, because R10 has no (*, G) state to match the traffic against.
A note on using PIM-SM with PIM-BiDir
PIM-SM and PIM-BiDir can co-exist in the network without any issues. However, on IOS-XE you cannot use the same loopback as the RP for both SM and BiDir at the same time. This is because the command show ip pim rp-candidate Lo0 will override the previous command. For example:
This becomes just:
Instead, you need to use two separate loopbacks:
Note that this is also the case for static RP and AutoRP.
However, on IOS-XR, this is not an issue. You can reuse the same loopback address for both modes.
Last updated
