Last updated
Last updated
Load multicast.init.cfg
Configure R2 to join (*, 239.2.2.2) and (*, ff08::2)
Configure R4 to join (*, 239.4.4.4) and (*, ff08::4)
Configure XR4 as the RP for group range 239.2.2.0/24 and ff08::2/128
Configure CSR9 as the RP for group range 239.4.4.0/24 and ff08::4/128
Use static RP assignment
Use R1 and R3 as the sources to verify that multicast traffic is working.
PIM-SM allows for ASM (any source multicast). In this mode, the receivers only know what group address they are interested in. The receivers are interested in traffic from any source (hence the name ASM).
The problem this introduces is: How can a LHR build a distribution tree when the receiver is interested in any source? Where would the LHR send the PIM Join? The solution to this problem is to use an RP (rendevous point). The RP is a common point in the network that all receivers can build a tree towards. In order to discover new sources sending to a given group address, the FHR must register all sources with the RP. This is done with a unicast PIM Register message. The RP then builds a (S, G) tree rooted at the sender, and “glues together” the source and receivers because it is the common point of the (S, G) and (*, G) trees. At this point, the LHR has also learned the source, and can now switchover to a (S, G) so that the distribution tree is taking the most optimal path.
All routers in the PIM domain must agree on the RP address. This can be configured statically or discovered dynamically through AutoRP or BSR. In this lab we simply manually define the RP mappings on each router. An RP can be defined on a per-multicast group basis. To demonstrate this, this lab requires you to configure a separate RP for each group range. This is done by associating a standard ACL with the static RP definition.
IPv6 PIM-SM works exactly the same way. We define the RPs statically and associate an ACL.
Additionally, since we are using the loopback as the RP address, XR4 and R9 must enable PIM on their loopback interface. R9 will already have IPv6 enabled on the loopback by default. Without this step, the RPs will not accept PIM Registers.
We can confirm the RP mappings on routers in the core. On IOS-XE, we cannot see the explicit mappings based on the ACL, but we can see this on IOS-XR.
On IOS-XR we can also see this using show pim group-map. This is also a handy way to see the default group mappings. For example, we see how AutoRP works for DM by default, and the default SSM range.
On IOS-XR, the show pim ipv6 range-list provides similar output. All the FF3X::/32 ranges are built-in for SSM for IPv6.
On the LHRs, any groups matching these ranges will use the RP as the root of the tree. A (*, G) entry uses the RP for that group for the RPF check.
For example, on R5, we see a (*, 239.2.2.2) entry and a (*, ff08::2) entry. In both cases, the RP is used for the RPF check. This is the incoming interface, and the OIL is the interface towards the receiver, where the IGMP/MLD Join was received.
The S flag means Sparse mode is used. The C flag means that the router is acting as LHR, because a received is directly connected. The J flag means that the router will switchover to the shortest path tree on the next received packet, meaning switchover to the (S, G) tree once the source is learned.
We can also see this on XRv3 as the LHR:
The A flag means Accept, and the F flag means Forward. The LI flag means Local interest, so the receiver is directly connected. In general, the NS flag is used to mean that received traffic should trigger some type of control plane activity. On an interface in the OIL, the NS flag means that received multicast traffic should trigger the PIM Assert process. On the IIF, the NS flag means that received multicast traffic should trigger the SPT switchover process.
The LHRs will send a PIM Join out the RPF interface, towards the RP. Because the next upstream router also has the same RP configured for the given group, the PIM Joins will eventually make their way to the RP. If the RP is not configured the same on all routers, this process will fail, and the tree from the RP to the receivers will not be setup correctly. This is why auto-discovery methods were created for RP information dissemination.
At the RPs, we see that the (*, G) state has been created. Let’s first check R9.
Strangely, R9 does not appear to be acting as an RP for IPv6 PIM. We can see that it does not create its own decap tunnels pointed towards itself. It only creates tunnels towards XR4.
The issue appears to be due to the ACL. I’m not sure if this is a bug or expected behavior. I found that I had to put the group range in the destination section in the IPv6 ACL. Also, R9 would not accept a /128, only a /127 or larger.
R9 now has the PIM decap tunnel:
XR4 works for both IPv4 and IPv6 with no issues:
XR4 shows us that these (*, G) entries have an incoming interface of a decapsulating tunnel. This is used for the PIM register process. Upon learning of an RP, all PIM routers will auto-create tunnels used to encapsulate multicast traffic into a PIM register message which is unicast to the RP. This is used by the FHR to register the source with the RP. The RP also auto-creates decapsulation tunnels, which allow the RP to decapsulate this traffic. (Remove the outer IP header and forward the inner multicast packet down the shared tree). We can see the auto-created tunnel interfaces using the following command:
Let’s now watch the Register process take place. We’ll use debug ip pim on the FHR, R7. We’ll ping 239.2.2.2 from R1.
R7, upon seeing multicast traffic, looks up the group address and finds that XR4 is the RP for the group. R7 creates (S, G) state and Registers the packet with XR4 via a unicast PIM Register packet (13:31:12.251).
The RP, upon seeing that it has interested receivers for the group based on the (*, G) entry, joins a (S, G) rooted at the newly discovered source (7.1.7.1). R7 receives this at 13:31:12.290. R7 adds Gi2.574 to the OIL for the (S, G) entry. R7 continues sending PIM Registers to XR4 incase the (S, G) is not actually working (13:31:13.246, 13:31:13.254). Once the RP sees that traffic is arriving natively via the (S, G) tree (not the PIM Registers), the RP sends a Register Stop to the FHR (13:13:14.266). The RP can differentiate traffic arriving via PIM Registers compared to natively on the (S, G) entry because the multicast traffic via the PIM Register requires the decapsulation of the outer PIM Register header.
This process works the same way for IPv6 traffic:
The FHRs, CSR5 and XRv3, only have a single path upstream. So no switchover occurs here. Instead the branching point is where the switchover occurs. The FHRs still join (S, G) trees, but they do not prune themselves off the shared tree. Only the branching point router prunes itself from the shared tree.
For example, for the (R1, 239.2.2.2) tree, XR1 is the branching point. XR1 notices that the source R1 is reachable via a different interface from the RPF interface, so XR1 switches over to a (S, G) tree. CSR5 sends the (S, G) Join, which makes its way to XR1. XR1, upon seeing that the (S, G) interface is different from the RPF interface, sends an RPT-bit (S, G) prune towards XR4, to prune itself off (*, G) just for this one source. This allows other sources sending to the same group in the future to continue to work. (This means to prune XR1 off the shared tree but just for (S, G). The RP then removes the interface from its (S, G) entry but not from its (*, G) entry.)
Note that on IOS-XR as the LHR, it is normal to see “no interfaces in immediate olist” for the (S, G) entry under show pim topology:
My guess is that this is because the (S, G) entry was not created via a IGMPv3 SSM join, but instead via a switchover event. In any case, the (S, G) entry in the MRIB shows the correct OIL:
PIM-SSM requires quite a bit of complexity in order to support ASM. We need an RP to use as a proxy to build a distribution tree for (*, G) entries. Then sources need to be registered with the RP, so that the traffic can be merged with the RP tree and distributed to interested receivers. If left in this state, the RP would take on the burden of processing all multicast traffic in the network. The traffic may also take a non-optimal path. To solve this, an SPT-switchover process is used so that the LHR simply joins the (S, G) tree once it learns of the source.
