10alt" />
CCIE DC Multicast Part 2
发布时间:2017-03-03   浏览次数:   分享:

CCIE DC Multicast Part 2


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:



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:


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

A Source can then generate traffic to 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?


 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?


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


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)



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.


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:


 Router(config-if)#ip igmp version 3


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

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

*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, type 5

*Feb  3 17:42:52.575: IGMP(0): Add Source Record*Feb  3 17:42:52.575: IGMP(0): Add Group Record for, 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


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, 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 range has been set aside by the IETF for use on the internet for SSM multicast. 范围已经被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.


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




interface GigabitEthernet1/0

 ip address

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

 ip igmp join-group source

 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, 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, type 6

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

*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#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


(*,, 00:09:50/00:02:12, RP, flags: DL

  Incoming interface: Null, RPF nbr

  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:


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

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




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

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

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