400-618-8070

10alt" />
新闻资讯
News
企业新闻
CCIE DC Multicast Part 2
发布时间:2017-03-03   浏览次数:   分享:

CCIE DC Multicast Part 2

本文提供:乾颐堂DC马海波

Hi Guys! In my last blog post, we had a quick look at multicast and a more in depth look at how PIM  works, since this is a CCIE DC focused blog, and the Nexus 7000 uses PIM Sparse Mode, we spent most of our time looking at Sparse Mode and the way shared trees and shortest path trees work, including the shared tree to shortest path tree switchover.

在上一篇博客中,我们快速了解了组播和一些PIM工作方式。因为这是关注CCIE DC的博文,Nexus 7000使用是sparse mode,我们花费了很多时间在sparse mode上以及共享树和最短路径树的工作方式和切换方式


Incidentally, before going any further, for a great review of the multicast concepts head to:

巧合的是,在继续进展之前,有一个不错的链接可以更好地复习一下组播概念

http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6552/prod_presentation0900aecd8031088a.pdf


If any of the above doesn't make sense to you, or you just want to brush up on your PIM Sparse mode, I strongly recommend you take a look at my first blog post, the concepts we are about to discuss all really depend on understanding PIM Sparse Mode. OK! Let's start!

如果有任何不理解的,或者你就是想温习一下sparse mode,我强烈建议你看看我前面的博文,让我们开始:

So when we spent time talking about PIM we looked at how when a receiver wants to join a multicast group, the closest router to that receiver (also known as the last hop router) will send a message up the tree to the RP to say hey, this guy wants to start receiving multicast so start getting the interfaces ready to start forwarding.

因此,当我们花时间谈论PIM的时候,我们看的是当一个接收者想加入一个组播组时,靠近接收者(也是最后一跳路由器)是如何在发送一个消息给树上的RP,say hey,说这个伙计想接收组播,所以打开端口准备转发。


We kind of glossed over how the device itself tells the router it wants to start receiving the multicast though, this happens via IGMP. In simple terms an IGMP message tells the router that the host wants to receive the multicast, you can have a router join a multicast group with:

我们想想设备自己如何告诉路由器它想接收组播流,这是通过IGMP实现的,简单的说,IGMP消息告诉路由器,这个主机想接收组播,用下面的命令你可以让一个路由器加入一个组播组:


ip igmp join-group 239.1.1.1 (where 239.1.1.1 is the multicast group you want the device to join)

A Source can then generate traffic to 239.1.1.1 and start receiving the multicast stream.

一个源可以生成组播流量到239.1.1.1 和接收组播流

Everything looking fine and dandy so far? OK, here are a few problems with this approach:

至今所有事情看起来很好,ok, 那这有一些问题和想法

 

 What happens when two sources are transmitting to the same multicast address? the receivers will receive two streams, wasting network bandwidth

当两个源正在传输流量到相同的组播地址会发生什么,接收者将接收两个流,浪费带宽


 A malicious user could start sending traffic to a multicast address and have it delivered to multiple hosts, potentially knocking them off the the network or degrading performance or interfering with the legitimate multicast application

一个恶意用户能发送流量到一个组播地址,让它转发到多个主机,潜在的攻击他们的网络降低性能

 We need an RP to discover the devices that want to receive multicast traffic, and we also need an RP for the first multicast frame from the source to reach our receiver (then we switch to a shortest path tree), what if our RP dies?

我们需要RP去发现那些想接收组播流的设备,同时我们也需要RP完成第一个组播帧从源传输到接收端,如果RP挂掉怎么办?


 If i am trying to build multicast applications for the internet (something which I would like to point out, doesn't really seem to have happened yet unless I am mistaken, do you know of a multicast application used out on the internet? Let us know in the comments section! :)) who runs the RP? Which ISP? Why do I trust them? Without an RP how do I learn about multicast sources and who wants to receive the traffic?

如果我想为互联网建立组播应用(谁是RP,谁是ISP,我们为何信任它们,没有RP,如何学习组播源和谁想接收组播)

These problems have been solved with IGMPv3 and SSM (Source Specific Multicast), Let's see how.

这些问题已经被IGMPv3和SSM解决,让我们看看如何解决的:


First of all, Let's quickly look at an IGMP Packet: (Picture source article: http://www.cisco.com/en/US/docs/ios/solutions_docs/ip_multicast/White_papers/mcst_ovr.html#wp1015526)

 

首先,我们快速看看IGMP包:

As you can probably tell from the above picture, with such a small type field, IGMP version 1 which is illustrated above is not exactly a complicated protocol. The host sends an IGMP Packet requesting to join the group address listed in the packet.

从图片看到,在这个小的字段里,IGMPv1不是一个复杂的协议,主机发送一个IGMP包请求去加入图标里列出那块组播地址

IGMP Version 2 added some extra message types that are not relevant to our discussion at the moment, the important thing is to see that the only major field this packet contains is a group address that wishes to be joined.

IGMP v2添加了一些额外的消息类型,跟我们现在讨论不太相关的,最重要的一点看到这个包的主要字段里还是只包含了一个想加入的组播组地址

Below is an IGMPv3 Packet:

As you can see, this packet not only contains the group we wish to join, but a source field, which can be used to specifiy "I want to join this multicast stream from THESE sources".

你可以看到,这个包不仅包含我们想加入的组播组,还有源字段,这个能被用来标示,我想加入组播流来自这些源的组播组

Here things get interesting.

事情开始变得有趣了

Let's assume our host knows what multicast group it wants to join and also knows the source address, this could have been learnt via some sort of external directory of multicast sources, like a webpage or something like that. The important thing to know is, somehow our host has discovered the group it wants to join, and what sources it should expect traffic from.

假设我们的主机知道它想加入的组播组,同时也知道组播源地址,这可以通过外部像一些网页看到一些组播源地址目录知道源地址,总之,重要的是如何让我们的主机知道它想加入的组播组和它想接收源自谁的组播流

Here is an example of the packets generated when we join a group using IGMPv3 on a router:

当我加入一个IGMPv3路由器的时,这有一个包生成的例子:

 Router(config-if)#ip igmp version 3

 

Router(config-if)#ip igmp join-group 232.1.1.1 source 1.1.1.1*Feb  3 17:42:52.567: IGMP(0): WAVL Insert group: 232.1.1.1 interface: GigabitEthernet1/0Successful

*Feb  3 17:42:52.571: IGMP(0): Create source 1.1.1.1

*Feb  3 17:42:52.571: IGMP(0): Building v3 Report on GigabitEthernet1/0

*Feb  3 17:42:52.575: IGMP(0): Add Group Record for 232.1.1.1, type 5

*Feb  3 17:42:52.575: IGMP(0): Add Source Record 1.1.1.1*Feb  3 17:42:52.575: IGMP(0): Add Group Record for 232.1.1.1, type 6

*Feb  3 17:42:52.579: IGMP(0): No sources to add, group record removed from report

*Feb  3 17:42:52.579: IGMP(0): Send unsolicited v3 Report with 1 group records on GigabitEthernet1/0

 

From the above we can see that an IGMP membership report is being sent out and we are specifically saying we want the source to be 1.1.1.1.

通过上面我们看到一个IGMP成员report正在被发送,而且特别说我们想加入1.1.1.1的组播源

IGMPv3 is going to be used for a host of reasons, but our main concern with it for our CCIE DC is it's use in SSM (Source specific multicast), SSM in combination with IGMPv3 means that we already now know the source address of the multicast stream, we don't need an RP to tell us that: the receiver requesting the stream has told us via IGMPv3! So since we already know the Source address, we can just send a normal join request up the tree towards the source! No more shared trees, yet we are still using PIM Sparse Mode, Hooray!

IGMPv3被主机使用的原因里,我们主要关心它对于CCIE DC里考到SSM, SSM配合IGMPv3意味着我们已经知道组播流的源地址,我们不需要RP来告诉我,接收者通过IGMPv3已经被告诉了,所以我们已经知道源地址,我们可以直接发送正常的join request到树上到源端,不在需要共享树,而且我们依然使用的是sparse mode。

SSM has other advantages too, because we are now joining multicast groups based on an (S,G) Entry, because the S is always unique, we can avoid multicast collision, let's say for example you wanted to stream out on the internet, you have this great idea for "the next youtube" using multicast, so you start sending multicast traffic to 238.0.0.1, what's to stop someone else using that exact same address at some point in time to stream THERE multicast traffic? Why should the ISP your using forward this traffic for you? How do they know you have receivers who really want to hear this traffic? With SSM every multicast stream is unique because the multicast route is (S,G), not (*,G)


SSM有另一个优点,因为我们是基于一个(S,G)条目加入组播组的,由于S是唯一的,我们避免了组播的冲突,举个例子,你想传送组播流到互联网,比如你有个想法为下一个youtube使用组播,所以你想发送组播流到238.0.0.1,怎么停止其他人也使用相同的地址传输它的组播流量,为什么ISP为你转发组播流,如何让接收者知道真正的想接收的源,用SSM每个组播流都是唯一的,因为组播路由是(S,G), 而不是 (*,G)

The 232.0.0.0/8 range has been set aside by the IETF for use on the internet for SSM multicast.

232.0.0.0/8 范围已经被IETF用于分配给SSM组播

Let's load up our topology files and start checking this out!

让我们继续加载实验环境,检查它:

If you read my first Multicast post, you will know that this is a LIVE follow along blog post that you can try out yourself, all the config's you need for GNS3 and the topology file is available: here

 

Here is a diagram of the network:

 Ok let's get started.

OK,让我们开始:

Once you have enabled PIM sparse mode on all interfaces, the only remaining bit of configuration is to enable SSM for your multicast range with the following command on each router (Except the source and receiver routers)

一旦你在所有接口开启PIM sparse mode,唯一保留的配置是开启SSM,利用下面的命令在每个路由器上(除了源路由器和接收路由器)

ip pim ssm default

 

The default keyword tells PIM to treat the range 232.0.0.0/8 as an SSM range, you could specify any range you wanted here however.

这个default 关键字告诉PIM使用232.0.0.0/8作为SSM组播范围,当然你可以使用你想用的任意范围

Let's take a look at what happens when our receiver joins the multicast group.

看一下当接收者加入组播组后发生了什么:

Receiver1:

 

interface GigabitEthernet1/0

 ip address 2.2.2.1 255.255.255.0

 ip pim sparse-mode   个人感觉接收端不用开这个

 ip igmp join-group 232.1.1.1 source 1.1.1.1

 ip igmp version 3

You can see the config....

 

You see the messages get sent:

debug ip igmp

 

eb  3 18:56:55.539: IGMP(0): Building v3 Report on GigabitEthernet1/0

*Feb  3 18:56:55.543: IGMP(0): Add Group Record for 239.1.1.1, type 5

*Feb  3 18:56:55.547: IGMP(0): No sources to add, group record removed from report

*Feb  3 18:56:55.551: IGMP(0): Add Group Record for 239.1.1.1, type 6

*Feb  3 18:56:55.551: IGMP(0): Add Source Record 1.1.1.1

*Feb  3 18:56:55.551: IGMP(0): Send unsolicited v3 Report with 1 group records on GigabitEthernet1/0

 

But for some reason... the multicast routing table on PIM2 does not update

但是一些原因,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.1.40), 00:09:50/00:02:12, RP 0.0.0.0, flags: DL

  Incoming interface: Null, RPF nbr 0.0.0.0

  Outgoing interface list:

    GigabitEthernet2/0, Forward/Sparse, 00:09:37/stopped

 

 

Let's investigate further, perform a debug ip igmp on PIM2 and you will get your answer:

让我们继续检查,执行一个PIM2的debug,你得到下面的答案:

... ... ... ... ... ...

... ... ... ... ... ...

官网字数限制,完整的技术文档可向官网客服索取。

乾颐堂客服热线:400-618-8070

乾颐堂官网:www.qytang.com

乾颐堂网络实验室 我们为您想的更多

 ©2013-2014  乾颐堂网络工程师培训  版权所有  京ICP备14044984号-2 

 中国权威 Cisco (思科) CCNA CCNP CCIE 认证培训 企业定制培训

 咨询报名电话:400-618-8070   

CCNA论坛