You never stop learning. One topic that hadn’t crossed my path in the past decade is: Multicast. Whew. Alongside all the technical literature, online presentations, and various blog posts, I decided to approach it the classic way – through packet captures. ;)

So here’s a new part of the #UltimatePCAP, which contains quite a bit of PIM traffic, including Hello, Join/Prune, Register (via unicast!), and more. Of course, for IPv6 and legacy IP (IPv4). Let’s have a look:

Please note that I’m *not* a multicast expert. Luckily, there are many good resources out there. I recommend this Cisco Live presentation from Aleksandar Sofranic (YouTube): IP Multicast Introduction and Troubleshooting, or this (partially free) multicast course on NetworkLessons.com, or this blog post series from Emil Boklund.

Lab Setup

This is my lab, consisting of 2x Cisco router 2811 with IOS version 15.1(4)M12a and 1x Palo Alto Networks firewall PA-440 with PAN-OS 11.1.10-h1 (which only supports legacy IP for multicast, not IPv6). Everything is routed via OSPF/OSPFv3, while PIM is used for multicast traffic. The rendezvous point (RP) is statically configured on R1’s loopback address. A Raspberry Pi on the right-hand side is offering a multicast stream. Three clients are placed in the lab to receive the streams. The capture point was between the routers R1 and R2, leveraging a real TAP, namely the ProfiShark from Profitap.

Raspberry Pi ffmpeg stream (thanks to this Reddit posting):

Similar for IPv6:

The clients/receivers used VLC to play the streams via udp://@239.23.11.10:1234, respectively udp://@[ff05::2311]:1234.

It’s Capturing Time!

This was the sequence of events that I captured for IPv4 on 2025-11-26. All times in UTC:

• 15:27 – cable between R1 and R2 was plugged into/through the TAP
• 15:31 – start of ffmpeg on the Raspberry Pi, sending to 239.23.11.10 on port 1234
  • 15:34 – client 1 starts listening to the multicast stream via VLC
  • 15:36 – client 1 stopped viewing (stream is cropped in the PCAP)
• 15:42 – stop of ffmpeg on the Raspberry Pi
  • 15:49 – client 1 starts again, though the stream is not present anymore
  • 15:50 – client 1 stops
• 15:51 – client 2 starts VLC, though the stream is not present
• 15:53 – client 2 stops

For IPv6, the following sequence was captured on 2025-12-03, all times are in UTC as well:

• 11:07 – cable between R1 and R2 was plugged into/through the TAP
• 11:10 – start of ffmpeg on Raspi, sending to [ff05::2311]:1234
  • 11:12 – client 3 starts listening to the multicast stream via VLC
  • 11:14 – client 3 stops
• 11:16 – stop of ffmpeg on the Raspi
  • 11:22 – client 3 starts again, though stream not running
  • 11:23 – client 3 stops

Some notes concerning the capture:

• I left only the beginning of the actual H.264 streams in there to keep the file as small as possible. (Can you decode them? ;))
• Neither IGMP (for IPv4) nor MLD (for IPv6) is interesting in this capture, as I captured between the two routers R1 and R2 rather than on the source or destination subnet of the multicast stream. Hence, we’re merely looking at PIM here.
• I don’t know why there’s PIMv1 traffic in there, since PIMv2 is the default at all.
• For IPv4, there are some unrelated PIM joins in there, as the clients requested some other multicast groups as well.
• Concerning IPv6, there’s a lot of ICMPv6 traffic in the capture, which relates to RS/RA, NS/NA, and MLD. I left them within the trace, as I left ARP for IPv4 there as well.

Wiresharking

Please download the UltimatePCAP by yourself in order to have a closer look at all those packets and sessions. The following screenshots give a rough overview, though.

5x for legacy IP, 5x for IPv6:

Shows & Configurations

Here are some multicast routing table outputs during the tests, all taken from R1:

As the stream started, but nobody was listening yet:

Client 1 listens to the stream:

Stream was not present anymore, client 2 requested it:

Same for IPv6: Stream started, no one listening yet:

Client 3 listens to the stream:

Stream not present anymore, client 3 requesting it nevertheless:

For the sake of completeness, here are the configuration commands related to IP routing and multicast for both routers:

Soli Deo Gloria!

Photo by 愚木混株 Yumu on Unsplash.