In this video, we'll dissect a PIM Hello packet.
If you've never seen Wireshark before,
I highly recommend that before we get too much further in the course,
you spend a little time looking at Pluralsight's
extensive library of Wireshark courses, starting with the basics.
I won't spend a lot of time explaining the layout of a packet capture here.
It would be exhaustive, and frankly,
boring to simply call out every line of this capture.
But since this is the first time we'll be looking at it together,
I'll spend a little extra time on the details of this one.
When we look at later captures, I'll focus on the exact parts that matter.
I've expanded the Ethernet frame section so we can take a look.
I'm not going to dive into layer 2 multicast in this course,
but I wanted to point out a couple things to pay attention to.
First, the destination MAC address is a multicast MAC.
We know this because it begins with 01:00:5e and fits
within the multicast MAC scope.
In fact,
since the destination is a logical group and not a physical device address,
the MAC is derived from the multicast group itself.
If we converted the MAC address from hex to binary,
we would get to 224.0.0.13, which is the ALL‑PIM‑ROUTERS group.
Next is the IPv4 section of the packet.
While the packet header contains a ton of information,
we're primarily concerned at this layer with the Source
and Destination IP of the packet.
The source address is 10.10.255.1, which is the router sending the PIM Hello.
The destination address is not the other router,
but all PIM routers on the segment.
Other than that, the most important part here is the Protocol flag,
which indicates that it's PIM.
Let's move on to the main event, the PIM packet.
We can see right away that we're working with PIM version 2.
Version 2 is the standard, and you shouldn't really see version 1 in production.
PIM V2 introduced improvements over version 1,
some of which we'll explore in detail, such as the bootstrap router feature.
More generally though,
the packet format was simply made more flexible and PIM V2 now has its own IP
protocol instead of relying on IGMP as the carrier protocol.
The PIM packet type is Hello, which is Type 0.
There are multiple types of PIM packets,
and we'll explore a lot of them in this course.
Moving on, we get to the PIM Options.
Not every PIM packet contains every PIM option,
so let's discuss these here,
and we'll cover the other options as we see them in other PIM packet types.
Option 1 is the Hold Time; this is the time in seconds that a PIM
neighbor will keep a neighbor adjacency before tearing it down if
it hasn't received another Hello.
Of course,
if router's link were to fail or some of their failure event were to occur,
this could cause the Hold Time to become relevant and the
adjacency be torn down immediately.
The Hold Time is just the maximum wait time before
declaring the PIM neighbor down.
Option 20 is the Generation ID.
Per the RFC, a router, on boot,
generates a pseudo random number called the Generation ID for each PIM
interface and appends it to its PIM Hello packets.
When routers first build an adjacency with the PIM neighbor,
they keep track of that neighbor's GenID.
If the GenID changes in subsequent Hello packets,
this serves to advise neighbors that the router has restarted and
may require a triggered multicast state refresh,
such as resending the PIM joins.
Option 19 concerns the Designated Router Priority and is
used when electing a DR on the segment.
In the demo preceding this section,
we explored how DR Election works and how to modify the DR Election process.
Now that we're pulling apart the PIM Hello,
we can see exactly how that DR priority is conveyed between neighbors.
Option 21 is special because it only affects PIM dense mode.
We haven't touched on PIM dense mode yet,
so it may be hard to talk about this one in detail.
Let's revisit it when we know more about PIM dense mode operation,
and then this option will make more sense.
Option 65004 is a private option, Cisco proprietary.
PIM options in the 65001 to 65535 range are reserved for private use,
so this shouldn't be seen on non‑Cisco routers,
and indeed, it may not be supported on every Cisco platform.
The actual feature is called the RPF Proxy Vector.
The goal of the RPF Proxy Vector is to allow a router,
an edge router, specifically,
to influence a core router in what direction it should build
multicast state towards another edge router.
Something like this would be useful primarily in situations where the edge
routers have a neighborship built over the top of a core router and the core
routers are simply switching packets between them,
such as a BGP‑Free Core.
The RPF Proxy Vector option is used to help influence the correct
upstream path to the source when the intermediate routers may not be
able to do a reverse path forwarding check against the source because
the source subnet is not in the RIB.
It's not something I would memorize as there are other
more utilized multicast VPN technologies,
like MLDP and MVPN.
I'm including the explanation mostly for completeness.
In this module,
we talked about protocol independence and what it means for multicast.
We also covered best path determination and how forwarding loops are avoided.
There was a demonstration of how to create a PIM neighbors and
also how to elect a PIM designated router.
We finished by doing a deep dive on a PIM Hello packet to show how the protocol handles communications between neighbors.