The PIM register is an important part of PIM sparse mode. Without
source registration to a rendezvous point, no receiver can be
paired with a source, and no multicast traffic can flow. Equally
important is the PIM register stop,
which tells the First Hop Router to stop wasting bandwidth sending
multicast when no receivers have been identified. Before getting into
the details of the data inside the packet,
I want to call attention to its format.
We have an outer unicast encapsulation with a source of
10.255.10.254 and a destination of 1.1.1.1.
What follows is the PIM header and a message type flagging it as a PIM register.
The inter encapsulation shows that the payload is from the
multicast source at 10.99.1.100, but the destination of the
multicast group, 239.3.2.1.
This indicates a multicast data packet encapsulated inside a unicast packet.
We now know that this packet rides that PIM tunnel that gets brought up
between every PIM router and the RP just for this purpose.
Okay, let's get into the details.
The PIM register is message type 1, and there are two PIM options of note. The
Border flag covers something beyond the scope of this course,
which is inter domain multicast, and it's not used very often.
The Null‑Register flag is not set in this case, but it will
be set in a future packet to the RP to refresh the RP's
register stop timer, if necessary.
The actual payload is just an ICMP packet being used to test
multicast flows in the lab. But notice that it's multicast data being
sent from the source to the multicast group.
The PIM register stop is sent from the RP back to the First Hop Router.
We can see that here. The source is the RP, and the
destination IP is the First Hop Router.
The register stop is PIM message type 2. From a PIM options perspective,
it's very straightforward.
The RP is simply signaling to stop the delivery of traffic sent to 239.3.2.1 from the source 10.99.1.100.