We're going to take a look at a few well‑known packet captures here and
see what's special about them in bidirectional PIM.
I won't spend a lot of time _____ laboring things that we've already
talked about. Instead I'll focus on the pieces that matter for BiDir
only. First is something I didn't cover in the previous explanations,
but I think is extremely important to know. Bidirectional PIM is a
negotiated PIM option.
BiDir is configured per router, so technically it could exist
on one end of a link and not the other.
This is really inadvisable.
Given what we know the difference between how bite here
operates and every other pin implementation,
it would be very easy to create multicast routing loops when
some routers are assuming a DF election is taking place and
other routers are ignoring it altogether.
Also imagine the pain of some routers simply forwarding traffic of a
bidirectional interface to an upstream router that isn't using it.
Let's take a quick look at the pin joined prune next.
Honestly, the pin joined.
Fruit and bidirectional pim isn't at all different from the
packet we've seen in other implementations.
Remember the real differences between My dear pin and
other implementations have to do with DF election and the
by deer pin upstream interface.
The joint itself is basically just in any source joined.
Our upstream neighbor is the designated border for the segment
as before the request is for group 239.3 dot 2.1 And the
source is the phantom r p address.
This will be forwarded up towards the RP link to build the oil as it would in a normal, sparse mode deployment.