CCIE DC Multicast Part 3.

Hi Guys!

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).

这里是组播实验的第三部分，希望你已经阅读了前两篇，关于组播共享树源树和SSM相关

The next thing we need to look at is Bi-Directional PIM.

下面的内容我们需要学习BIDir双向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?

记得在SSM特定源组播我们如何需要Sparse-mode PIM，但是由于在IGMPv3的增强能力包含组播流的源地址，因此不需要RP，因此基于源的树可能更效率，尽管我们使用了PIM Sparse模式

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.)

Bi-Dir相反，什么都是共享树的，但是流量是可以双向（一会解释什么意思）

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?

为什么我们想让任何事情都是共享树？我们建立SSM不是挺好的吗？ 它可使用更效率的基于源的树啊。

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.

想象一个庞大的组播流量网络，有很多的源和接收者（多对多组播应用网络），一个网络可能在组播路由表里迅速添加成百上千的（S，G）组播条目，而组播最主要的应用是金融服务，股票市场，在当今高频交易的环境下，延迟是一个大大不可以。

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.

这么多的组播条目将使交换机变慢，变得低效率，因此，我们有双向PIM，想法就是如果什么都是用共享树，我们可以减少组播路由表条目，只用（，G），当使用一个组播地址带多个源时，这个效率就真的变得有意义了。

Now we get into the Bi-Directional part of the discussion.

现在我们开始Bi-Dir的讨论吧

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.

那么，当我们使用一个共享树，我们主要的问题是什么？就是它的不够效率的分发，另一个共享树的问题，如何当PIM Sparse mode还没有组播条目的时候让组播流从源到达RP，Sparse mode正常PIM是通过第一次使用单播传送的方式解决的，然后尽可能的转到基于源树的转发。

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.

Bi-Dir所做的就是，选择从源端到RP之间路径上的路由器作为“指定转发器”，这些指定的转发器被选择基于谁是最优到RP的路由器，这个指定转发器在每个LAN分段都会选取，因为组播流量都可能源自这些LAN分段

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.

你可以看到，流量从源穿越这个树到达RP，然后不管组播的基本规则（防环用的）：不再转发回组播流到组播流量的接收端口，Bir会怎么做，将转发到我们接收到组播的那个相同的接口，因为我们就是很牛逼.

Hence the term, Bi-Directional PIM.

这就是这个术语 Bi-Dir 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:

在PIM域每个路由器上使用下面命令开启，注意如果你想使用Bi-Dir PIM，你需要在所有网络范围都要开启它，下面是cisco的直接警告：

"Packet loops will occur immediately in networks that are only partially upgraded to support bidir-PIM."

只有部分设备升级支持bidir-PIM时，包环路会立即发生在网络。

Yikes! So hopefully you can see, enable it EVERYWHERE>

所以，希望你看到，要开启它在任何网络PIM范围。

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.

我们主要关心的开启Birdir的命令在顶端，send-rp-announce bidir不需要多关注，RP 发现我们将在下一章介绍

OK so now you have it enabled, let's keep investigating.

ok，现在开启后，我们继续观察

First of all, let's have a look at what happens on the routers in regards to the Designated Forwarder:

首先，我们看看路由器上的DF发生了什么

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?

检查高亮的部分这段，子网10.20.0.0，我们说我们在这个分段有个源，那谁是这个段的DF？

The DF election is based on whomever has the best metric to the address of the RP, let's check out some debugs:

DF选举基于谁到RP有最好度量的，让我们检查一下debug信息：

"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:

让我们一行一行检查，第一个段是正在发送v2获胜信息，（Pim1的G1/0是DF，他将转发组播流量到RP，获胜的原因是他到RP 2.2.2.5有110的优先级和2的度量，让我们检查单薄路由表）

"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!

知道了吗？单播路由表告诉的距离是110，度量是2

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.

所以，PIM检查谁是最近到RP的是基于单播路由表上的度量值，然后获胜者变成了这个网段的DF

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.)

你可以看到G3/0接口（面向RP的），PIM1直接连接RP的接口不是DF，因为RP发过来的度量更优

the Designated forwarder make sense? Check out the below for a bit more info

DF什么用途？查看下面更多的信息

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!!!

希望DF有它的作用，让我们看一下当产生一些组播的时候发生了什么

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...

你可以看到上面的输出，第一个看到的是路由器产生了一个共享树为每一个组播组，这是个父系条目，下一个是生成了一个共享树（*，239.1.1.1），标志位是B代表双向组，替换“入接口”我们有个词叫"BiDir-upstream"，在我们这情况是G3/0（流量源自），如果你注意，G3/0也在出接口列表，所以也可以让流量转发出去

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.

下面的事情你注意到00:02:06/Stopped，这个条目没有超时时间，因为这是DF所在的地方

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.)

在一次看组播如何工作的，我们注意到也有个bidir upstream在PIM2上，它作为出接口没有超时时间，BC位是BiDir和Connect直连接收者

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 .

这里你了解完了Bi-Dir，希望你能喜欢这篇

BiDir的个人总结：

1， RP 主要实现 DF的选举和BiDir-upstream 的选举，最终每个路由器产生默认（,G）表项

2 , 每个路由器上都有一个BiDir-Upstream接口， 其中到达RP的出接口网段的DF是作为BiDir-upstream 的上游neighbor

3， 配置RP Bir以后会产生一条默认（，224.0.0.0/4）组播表项

4， 组播源没有单播注册报文转发到RP，组播源是通过默认（，224.0.0.0/4）转发组播流到RP，组播源到RP路径之间没有（，G/32）表项，DF在（，224.0.0.0/4）里作为incoming入接口用于接收组播流量，然后由upstream接口转发给RP

5， 组播接收者与RP之间，DF转发join message 到RP，产生（，G/32）表项，DF在（，G/32）作为outgoing接口转发接口将流量转发到接收端

6，总结一句话：（，224.0.0.0/4）给组播源用的，（*，G/32）是给接收端用的