Here is part 3 of the Multicast Tutorials, Hopefully you have read the two previous posts here and here on multicast/Shared/Source tree's, and the post on SSM (Source Specific Multicast).
The next thing we need to look at is Bi-Directional PIM.
So remember how in SSM we had sparse-mode PIM, but due to the enhancements in IGMPv3 including the source address of a multicast stream AND the multicast group address that we want to join, there was no need for the RP, so more efficient, Source-based tree's could be made even though we where using PIM Sparse mode?
Bi-Dir is kind of the opposite of that, everything is a shared-tree, but traffic can flow bidirectional (We will get to what that means in a minute.)
Why would we want everything to be a shared tree? Didn't we just establish that SSM was great because it made everything use an efficient source-based tree?
Imagine a massive network of multicast traffic, with many sources and many receivers (a many-to-many multicast application network). A network like this would quickly add hundreds, even thousands and tens of thousands of (S,G), multicast entries in the mroute table. One of the major applications for Multicast is financial services, stock markets etc, and in today's climate of HFT (High-Frequency-Trading), latency is a big no-no.
All those multicast entries in the mroute table will slow the switch down, and start to make the switch inefficient, thus, we have Bidirectional PIM, the idea is that if everything uses a shared tree, we can reduce the number of mroute table entries down to just those with (*,G), when using one multicast group address with multiple sources, this efficiency really starts making sense.
Now we get into the Bi-Directional part of the discussion.
So, when we use a shared tree, what is our major issue with it? It's inefficient distribution. The other problem with a shared tree is: How does the multicast traffic from the SOURCE, get to the RP when PIM Sparse mode doesn't forward multicast traffic unless it already has entries? Sparse Mode normal PIM get's around this by delivering the traffic via unicast first, then switching to a source-based tree as soon as possible.
What Bidirectional PIM does, is elect routers along the path from the source back to the RP as "designated forwarders", these designated forwarders are elected based on who has the best route back to the RP. A designated forwarder is elected for every LAN segment, because the multicast traffic might be sourced from that LAN segment.
The topology we will use is shown below:
As you can see, traffic travels up the tree from the source, through PIM1 to the RP, and then, despite all the rules of multicast which essentially say "never forward multicast back through the interface it was received on" (A kind of loop prevention mechanism), what do we do? We forward back on the same interface we received from, Cause that's how we roll.
Hence the term, Bi-Directional PIM.
So without any further chit-chat let's see it in action.
On each of the routers involved in your bidir Pim, enable the following, note that if your going to enable Bi-DIR Pim, you need to do it NETWORK WIDE, here is the caution straight from cisco:
"Packet loops will occur immediately in networks that are only partially upgraded to support bidir-PIM."
Yikes! So hopefully you can see, enable it EVERYWHERE>
ip pim bidir-enable
ip pim rp-address 2.2.2.5
ip pim send-rp-announce GigabitEthernet1/0 scope 255 bidir
ip pim send-rp-discovery GigabitEthernet1/0 scope 255
The major commands we care about are the bidir-enable at the top, and the send-rp-announce bidir, don't worry too much about those commands at the moment, RP discovery will be covered in my next blog post.
OK so now you have it enabled, let's keep investigating.
First of all, let's have a look at what happens on the routers in regards to the Designated Forwarder:
Check out the section we have highlighted in the picture, subnet 10.2.0.0, let's say we have a IGMP source on this segment, WHO is the designated forwarder for this segment?
The DF election is based on whomever has the best metric to the address of the RP, let's check out some debugs:
"Pim1
Debug ip pim df
b 6 21:45:36.527: PIM(0): Send v2 Winner on GigabitEthernet1/0 (DF) for RP 2.2.2.5
*Feb 6 21:45:36.531: PIM(0): Sender 1.1.1.2, pref 110, metric 2
*Feb 6 21:45:36.531: PIM(0): Send v2 Winner on GigabitEthernet2/0 (DF) for RP 2.2.2.5
*Feb 6 21:45:36.531: PIM(0): Sender 10.2.0.1, pref 110, metric 2
*Feb 6 21:45:38.151: PIM(0): Receive DF Winner message from 10.0.0.2 on GigabitEthernet3/0 (Non-DF)
*Feb 6 21:45:38.155: PIM(0): RP 2.2.2.5, pref 0, metric 0
*Feb 6 21:45:38.155: PIM(0): Metric is better
*Feb 6 21:45:44.003: PIM(0): Receive DF Winner message from 10.0.0.2 on GigabitEthernet3/0 (Non-DF)
*Feb 6 21:45:44.007: PIM(0): RP 2.2.2.5, pref 0, metric 0
*Feb 6 21:45:44.007: PIM(0): Metric is better
"
Let's examine these line by line, the first statement is that we are sending out a v2 Winner (Pim1 is the designated forwarder for int gi1/0, he will forward multicasts for that segment up to the RP, the reason he is the winner is because his routes are pref 110, metric 2 to the RP address 2.2.2.5, let's check the unicast routing table:
"PIM1#show ip route 2.2.2.5
Routing entry for 2.2.2.0/24
Known via "ospf 1", distance 110, metric 2, type intra area
"
Well whatya know? The routers unicast routing table says the distance is 110, and the metric is 2, funny that!
So PIM checks to see who is closest to the RP, based on the metrics in the unicast routing table, and the winner of that becomes the DF for that segment.
You can see that on interface gi3/0 (the interface that faces the RP), that PIM1 has conceded it is not the DF, because the metric sent to it by the RP is better (in this case it's pref 0 metric 0, because 2.2.2.0/24 is directly connected to the RP.)
the Designated forwarder make sense? Check out the below for a bit more info
PIM1#show ip pim interface df
* implies this system is the DF
Interface RP DF Winner Metric Uptime
GigabitEthernet1/0 2.2.2.5 *1.1.1.2 2 00:08:57
GigabitEthernet2/0 2.2.2.5 *10.2.0.1 2 00:08:57
GigabitEthernet3/0 2.2.2.5 10.0.0.2 0 00:07:43
Hopefully the designated forwarder is starting to make sense, let's look at what happens
when we actually generate some multicast! Woopie!!!
Receiver3(config)#int gi1/0
Receiver3(config-if)#ip igmp join
Receiver3(config-if)#ip igmp join-group 239.1.1.1
Receiver2(config)#int gi1/0
Receiver2(config-if)#ip igmp join-group 239.1.1.1
Source1#ping 239.1.1.1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.1.1.1, timeout is 2 seconds:
Reply to request 0 from 10.1.0.1, 64 ms
Reply to request 0 from 2.2.2.1, 68 ms
Our multicast worked! Let's have a look at which tree was generated:
PIM1#
PIM1#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*,224.0.0.0/4), 00:13:25/-, RP 2.2.2.5, flags: B
Bidir-Upstream: GigabitEthernet3/0, RPF nbr: 10.0.0.2 Incoming interface list:
GigabitEthernet3/0, Accepting/Sparse
GigabitEthernet2/0, Accepting/Sparse
GigabitEthernet1/0, Accepting/Sparse
(*, 239.1.1.1), 00:02:06/00:03:21, RP 2.2.2.5, flags: B
Bidir-Upstream: GigabitEthernet3/0, RPF nbr 10.0.0.2 Outgoing interface list:
GigabitEthernet2/0, Forward/Sparse, 00:02:06/00:03:21
GigabitEthernet3/0, Bidir-Upstream/Sparse, 00:02:06/stopped
You can see from the above output that the first thing the router does is create a shared tree for every single multicast group (224.0.0.0/4), this is the parent entry for all multicast groups. The next thing that happens is that the shared tree (*,239.1.1.1) is created, the flag shows B for bidirectional group, and instead of "incoming-interface" we have the words "BiDir-upstream" which in this case is Gi3/0 (where the traffic is sourced from), if you notice.. Gi3/0 is also in the outgoing interface list, so will have the traffic forwarded out of it...
The next thing you will notice is the 00:02:06/Stopped, that is because this entry will never time out, because this is where the designated forwarder is.
Let's take a look at PIM2:
PIM2#show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*,224.0.0.0/4), 00:03:30/-, RP 2.2.2.5, flags: B
Bidir-Upstream: GigabitEthernet2/0, RPF nbr: 10.2.0.1
Incoming interface list:
GigabitEthernet1/0, Accepting/Sparse
GigabitEthernet2/0, Accepting/Sparse
(*, 239.1.1.1), 00:03:30/00:02:22, RP 2.2.2.5, flags: BC
Bidir-Upstream: GigabitEthernet2/0, RPF nbr 10.2.0.1
Outgoing interface list:
GigabitEthernet1/0, Forward/Sparse, 00:03:30/00:02:22
GigabitEthernet2/0, Bidir-Upstream/Sparse, 00:03:30/stopped
Again we see how the multicast works, we notice that there is a bidir upstream interface again and that it is set to never timeout, the flags also show BC for BiDir and Connected (a receiver is locally connected.)
There you have it, Bi-Dir! I hope you enjoyed this blog post. As I have mentioned previously, if you find it useful the best books i have ever found on multicast are linked below, please use my links below if you enjoyed my blog post :).
Multicast Book:
Hard Copy:
Kindle Version:
Routing and Switching Book:
Kindle Version:
Hard Copy:
As with most of your posts, I enjoy how you describe everything and connect thoughts to explain your point. Thanks Peter.
ReplyDelete