In this demo, we'll cover the PIM Graft and Graft‑Ack process.
We'll see how routers add new receivers to previously pruned interfaces
and how upstream routers acknowledge that request and then perform their
own until reaching the First Hop Router.
Let's assume that multicast traffic has been flooding into the
network with no receivers and then someone tunes into the
concert from their laptop while on break.
The network has already pruned all the interfaces from the stream,
so how can we cancel the prune and get the traffic flowing?
We need to turn on some debugs and then have the receivers
signal interest in the multicast group.
We'll see what happens here at the LHR,
and then we'll look upstream at another router.
The LHR router receives the IGMP report for the group.
Because it has knowledge of a source previously learned,
it creates a PIM Graft message to restart the upstream flow of traffic.
Interestingly, the router creates a PIM Graft for every PIM‑enabled interface,
but only forwards it to the upstream incoming interface with a
request to graft the source and group pair.
The Graft‑Ack is received from the upstream neighbor,
which allows the interface towards the receiver to
transition to a forwarding state.
Let's jump up the stream to MCAST4 and see what happened there.
MCAST4 received a downstream PIM Graft message on gig 1 for the source and
group pair and sent a Graft‑Ack to the PIM neighbor.
MCAST4 then crafts its own PIM Graft for each interface,
but only forwards it upstream based on the best path to the source.
This will repeat until the FHR adds the downstream to its OIL
and traffic flows down to the receiver.
The process is very similar to a PIM join and another PIM implementations,
but the PIM message is different, has a different PIM message type,
and is sent to be a unicast to the DR.
If a Graft‑Ack is not received,
the router will send another graft upstream after waiting some time.
In the next section, we'll be deep diving into the PIM packets and see how it looks in Wireshark.