I would read that sentence to the very end before jumping to conclusions :-)
> Routers that are not directly connected to receivers do not have to upgrade > to a Cisco IOS software image that supports SSM. In general, these nonlast > hop routers must only run PIM-SM in the SSM range, *and may need additional* > *access control configuration to suppress MSDP signalling, registering, or * > *PIM-SM shared tree operations from occurring within the SSM range.* So, unless you prevent other routers from being ASM in the range used by SSM, your SSM will not work unless SSM has been enabled on those routers. -- Marko Milivojevic - CCIE #18427 Senior Technical Instructor - IPexpert FREE CCIE training: http://bit.ly/vLecture Mailto: [email protected] Telephone: +1.810.326.1444 Web: http://www.ipexpert.com/ On Mon, Feb 7, 2011 at 11:08, Bojan Zivancevic <[email protected]> wrote: > OK, IGMP cleared. But that thing you mentioned about "ip pim ssm" was > confusing to me. I thought like you - it must enabled on all participating > routers. But look what's in the 12.4T config guide for SSM: > > > > http://www.cisco.com/en/US/docs/ios/ipmulti/configuration/guide/imc_cfg_ssm_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1000913 > > SSM Operations > > An established network, in which IP multicast service is based on PIM-SM, > can support SSM services. SSM can also be deployed alone in a network > without the full range of protocols that are required for interdomain PIM-SM > (for example, MSDP, Auto-RP, or bootstrap router [BSR]) if only SSM service > is needed. > > > > If SSM is deployed in a network already configured for PIM-SM (Cisco IOS > Release 12.0 or later releases is recommended), then only the last hop > routers must be upgraded to a Cisco IOS software image that supports SSM. > Routers that are not directly connected to receivers do not have to upgrade > to a Cisco IOS software image that supports SSM. In general, these nonlast > hop routers must only run PIM-SM in the SSM range, and may need additional > access control configuration to suppress MSDP signalling, registering, or > PIM-SM shared tree operations from occurring within the SSM range. > > > > It is clearly stated that all other (non-client-facing) routers can only run > SPARSE mode in the SSM range... without SSM ?? > > > > Also, the first section states that (maybe, I am not sure?) we can run SSM > without enabling PIM? > > > > thanks for the help... > > > > Best Regards, > > > > Bojan Zivancevic > > Network Engineer > > > > > > -----Original Message----- > From: Marko Milivojevic [mailto:[email protected]] > Sent: 07 February 2011 11:44 > To: Bojan Zivancevic > Cc: Tyson Scott; [email protected] > Subject: Re: [OSL | CCIE_RS] SSM config concept > > > > That's correct. You need to change IGMP version only on those interfaces > that are facing clients. You must however enable "ip pim ssm" on all routers > that will participate in SSM. I read in your original message that you > thought this was not a requirement - but it is. Otherwise those routers not > being aware of SSM groups will be running in ASM mode for SSM groups and > attempt to "talk to RP", which is non-existent in SSM networks. > > > > -- > > Marko Milivojevic - CCIE #18427 > > Senior Technical Instructor - IPexpert > > > > FREE CCIE training: http://bit.ly/vLecture > > > > Mailto: [email protected] > > Telephone: +1.810.326.1444 > > Web: http://www.ipexpert.com/ > > > > On Mon, Feb 7, 2011 at 09:22, Bojan Zivancevic <[email protected]> > wrote: > >> Thanks Tyson for such a detailed example! > >> > >> In a day or two I will repeat the test and compare the mroute output to >> this. Currently I am doing other exam-related stuff. > >> > >> I am not sure about one thing from your config though. Why did you enable >> IGMPv3 on all interfaces? It should be enough to do it on the client-facing >> side, right? > >> > >> Best Regards, > >> > >> Bojan Zivancevic > >> Network Engineer > >> -----Original Message----- > >> From: Tyson Scott [mailto:[email protected]] > >> Sent: 05 February 2011 03:06 > >> To: Bojan Zivancevic; [email protected] > >> Subject: RE: [OSL | CCIE_RS] SSM config concept > >> > >> SSM is a little more difficult to test with. Ping doesn't work because >> you need to define for which source you should receive the multicast traffic >> from. (Or at least let me say I have never been able to get it to work). > >> > >> Here is what I did to test it > >> > >> First configured SSM between three routers > >> > >> Windows 2003 > >> Server-NIC2===Fa0/1-R5-Se0/1/0====Se0/1/0.256-R2-Vi-temp1===Vi-temp1-R > >> 4-Fa0/ > >> 1====NIC2-Windows XP > >> > >> On Every interface I added > >> ip pim sparse-mode > >> ip igmp version 3 > >> > >> On the three routers I added > >> ip pim ssm default > >> > >> I downloaded the following application to generate some traffic > >> http://www-personal.umich.edu/~bdr/et/mcast-windows.html#download > >> > >> I put this on both the win2003 and XP. This application only supports >> IGMPv2. So I could use it to send mcast streams but not to receive. > >> > >> On windows 2003 server I typed in the following to get the above > >> application to stream multicast c:\mcast\bin\msender 232.10.45.10 > >> 10000 send multicast packet 1 to 232.10.45.10 10000 bytes 32 send > >> multicast packet 2 to 232.10.45.10 10000 bytes 32 send multicast > >> packet 3 to 232.10.45.10 10000 bytes 32 send multicast packet 4 to > >> 232.10.45.10 10000 bytes 32 send multicast packet 5 to 232.10.45.10 > >> 10000 bytes 32 send multicast packet 6 to 232.10.45.10 10000 bytes 32 > >> send multicast packet 7 to 232.10.45.10 10000 bytes 32 send multicast > >> packet 8 to 232.10.45.10 10000 bytes 32 send multicast packet 9 to > >> 232.10.45.10 10000 bytes 32 send multicast packet 10 to 232.10.45.10 > >> 10000 bytes 32 send multicast packet 11 to 232.10.45.10 10000 bytes 32 > >> send multicast packet 12 to 232.10.45.10 10000 bytes 32 send multicast > >> packet 13 to 232.10.45.10 10000 bytes 32 send multicast packet 14 to > >> 232.10.45.10 10000 bytes 32 send multicast packet 15 to 232.10.45.10 > >> 10000 bytes 32 > >> > >> now looking on the connected device I can see this traffic > >> > >> R5(config-router-af)#do sh 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, > >> 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 > >> > >> (*, 239.255.255.254), 02:32:48/00:02:11, RP 6.6.6.6, flags: SJC > >> Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2 > >> Outgoing interface list: > >> FastEthernet0/1, Forward/Sparse, 02:32:48/00:02:11 > >> > >> (4.4.4.4, 232.0.0.1), 1w2d/00:02:48, flags: sTIZ > >> Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2 > >> Outgoing interface list: > >> MVRF VRFA, Forward/Sparse, 1w2d/00:02:35 > >> > >> (5.5.5.5, 232.0.0.1), 1w2d/00:03:07, flags: sT > >> Incoming interface: Loopback0, RPF nbr 0.0.0.0 > >> Outgoing interface list: > >> Serial0/1/0, Forward/Sparse, 1w2d/00:02:47 > >> > >> (*, 233.10.45.10), 01:46:45/stopped, RP 6.6.6.6, flags: SPF > >> Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2 > >> Outgoing interface list: Null > >> > >> (10.1.1.100, 233.10.45.10), 01:46:45/00:01:26, flags: PFT > >> Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0 > >> Outgoing interface list: Null > >> > >> (10.1.1.100, 232.10.45.10), 00:01:23/00:02:56, flags: sPT > >> Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0 > >> Outgoing interface list: Null > >> > >> (*, 224.0.1.40), 1w2d/00:02:37, RP 0.0.0.0, flags: DPL > >> Incoming interface: Null, RPF nbr 0.0.0.0 > >> Outgoing interface list: Null > >> > >> R5(config-router-af)# > >> > >> > >> Notice the outgoing interface is currently NULL > >> > >> On the receiver I downloaded VLC and install this application > >> http://www.videolan.org/vlc/download-windows.html > >> > >> In VLC Media -> Network Stream > >> > >> I typed in the following > >> rtp://[email protected] > >> > >> When this was done then an IGMPv3 membership join request was > >> generated > >> > >> I turned on a debug ip igmp on R4 > >> > >> R4(config-if)# > >> Feb 5 01:39:58.275: IGMP(0): Received v3 Report for 1 group on > >> FastEthernet0/1 from 192.1.49.100 > >> Feb 5 01:39:58.275: IGMP(0): Received Group record for group >> 232.10.45.10, mode 3 from 192.1.49.100 for 1 sources Feb 5 01:39:58.279: >> IGMP(0): WAVL Insert group: 232.10.45.10 interface: > >> FastEthernet0/1Successful > >> Feb 5 01:39:58.279: IGMP(0): Create source 10.1.1.100 Feb 5 > >> 01:39:58.279: IGMP(0): Updating expiration time on > >> (10.1.1.100,232.10.45.10) to 180 secs > >> Feb 5 01:39:58.279: IGMP(0): Setting source flags 4 on > >> (10.1.1.100,232.10.45.10) > >> Feb 5 01:39:58.279: IGMP(0): MRT Add/Update FastEthernet0/1 for > >> (10.1.1.100,232.10.45.10) by 0 > >> R4(config-if)# > >> Feb 5 01:39:59.187: IGMP(0): Received v3 Report for 1 group on > >> FastEthernet0/1 from 192.1.49.100 > >> Feb 5 01:39:59.187: IGMP(0): Received Group record for group > >> 232.10.45.10, mode 3 from 192.1.49.100 for 1 sources Feb 5 > >> 01:39:59.187: IGMP(0): MRT Add/Update FastEthernet0/1 for > >> (10.1.1.100,232.10.45.10) by 0 > >> Feb 5 01:39:59.187: IGMP(0): Updating expiration time on > >> (10.1.1.100,232.10.45.10) to 180 secs > >> R4(config-if)# > >> > >> Notice that the receiver with the VLC player makes the Group request > >> for > >> 232.10.45.10 now > >> > >> Looking at the MROUTE table for R4 I see the following > >> > >> R4(config-if)#do sh ip mroute ssm > >> (5.5.5.5, 232.0.0.1), 1w2d/00:02:55, flags: sTIZ > >> Incoming interface: Virtual-Access3, RPF nbr 100.100.24.2 > >> Outgoing interface list: > >> MVRF VRFA, Forward/Sparse, 1w2d/00:02:51 > >> > >> (4.4.4.4, 232.0.0.1), 1w2d/00:03:25, flags: sT > >> Incoming interface: Loopback0, RPF nbr 0.0.0.0 > >> Outgoing interface list: > >> Virtual-Access3, Forward/Sparse, 1w2d/00:02:37 > >> > >> (10.1.1.100, 232.10.45.10), 00:07:44/00:02:56, flags: sTI > >> Incoming interface: Virtual-Access3, RPF nbr 100.100.24.2 > >> Outgoing interface list: > >> FastEthernet0/1, Forward/Sparse, 00:00:31/00:02:43 > >> > >> R4(config-if)# > >> > >> Notice that R4 is receiving the stream now from the neighbor > >> > >> R5(config-if)#do sh ip mroute ssm > >> (4.4.4.4, 232.0.0.1), 1w2d/00:02:36, flags: sTIZ > >> Incoming interface: Serial0/1/0, RPF nbr 100.100.100.2 > >> Outgoing interface list: > >> MVRF VRFA, Forward/Sparse, 1w2d/00:02:05 > >> > >> (5.5.5.5, 232.0.0.1), 1w2d/00:03:26, flags: sT > >> Incoming interface: Loopback0, RPF nbr 0.0.0.0 > >> Outgoing interface list: > >> Serial0/1/0, Forward/Sparse, 1w2d/00:03:05 > >> > >> (10.1.1.100, 232.1.1.100), 03:36:15/00:02:56, flags: sPT > >> Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0 > >> Outgoing interface list: Null > >> > >> (10.1.1.100, 232.10.45.10), 01:04:03/00:03:27, flags: sT > >> Incoming interface: FastEthernet0/1, RPF nbr 0.0.0.0 > >> Outgoing interface list: > >> Serial0/1/0, Forward/Sparse, 00:20:17/00:02:36 > >> > >> R5(config-if)# > >> > >> Now for a very short time on the receiver I can enable the second > >> application I am using to send the mcast traffic but it is going to > >> start using IGMPv2 after I do this which will cause R4 to prune the > >> group as it will ignore the v2 update packets for SSM type routes > >> > >> R4(config-if)# > >> Feb 5 01:37:26.187: IGMP(0): Received v3 Report for 2 groups on > >> FastEthernet0/1 from 192.1.49.100 > >> Feb 5 01:37:26.187: IGMP(0): Received Group record for group > >> 232.10.45.10, mode 2 from 192.1.49.100 for 0 sources Feb 5 > >> 01:37:26.187: IGMP(0): Group Record mode 2 for SSM group 232.10.45.10 > >> from 192.1.49.100 on FastEthernet0/1, ignored Feb 5 01:37:26.187: > >> IGMP(0): Received Group record for group 239.255.255.250, mode 2 from > >> 192.1.49.100 for 0 sources Feb 5 01:37:26.187: IGMP(0): Updating > >> EXCLUDE group timer for > >> 239.255.255.250 > >> Feb 5 01:37:26.187: IGMP(0): MRT Add/Update FastEthernet0/1 for > >> (*,239.255.255.250) by 0 > >> R4(config-if)# > >> > >> But for a short time before the v3 report is timed out I can see the > >> traffic > >> > >> C:\mcast\bin>mreceiver 232.10.45.10 10000 packet 1 - received group > >> 232.10.45.10 from 10.1.1.100:10000 32 bytes packet 2 - received group > >> 232.10.45.10 from 10.1.1.100:10000 32 bytes packet 3 - received group > >> 232.10.45.10 from 10.1.1.100:10000 32 bytes packet 4 - received group > >> 232.10.45.10 from 10.1.1.100:10000 32 bytes ^C C:\mcast\bin> > >> > >> > >> > >> Regards, > >> > >> Tyson Scott - CCIE #13513 R&S, Security, and SP Managing Partner / Sr. >> Instructor - IPexpert, Inc. > >> Mailto: [email protected] > >> Telephone: +1.810.326.1444, ext. 208 > >> Live Assistance, Please visit: www.ipexpert.com/chat > >> eFax: +1.810.454.0130 > >> > >> IPexpert is a premier provider of Self-Study Workbooks, Video on > >> Demand, Audio Tools, Online Hardware Rental and Classroom Training for > >> the Cisco CCIE (R&S, Voice, Security & Service Provider) > >> certification(s) with training locations throughout the United States, > >> Europe, South Asia and Australia. Be sure to visit our online > >> communities at www.ipexpert.com/communities and our public website at > >> www.ipexpert.com > >> > >> -----Original Message----- > >> From: [email protected] > >> [mailto:[email protected]] On Behalf Of Bojan > >> Zivancevic > >> Sent: Friday, February 04, 2011 11:42 AM > >> To: [email protected] > >> Subject: [OSL | CCIE_RS] SSM config concept > >> > >> Hi guys, > >> > >> I am struggling with SSM - but not with the theory concepts (at least that >> was my impression) but with the practical tests. Every doc I was able to >> find at the end led me to a confusion about what to configure and where. > >> > >> So, my conclusion about the concepts was: > >> > >> > >> - configure "ip pim ssm" only on the router directly > >> connected to the receivers > >> > >> - enable IGMPv3 on the segment where the receivers are > >> > >> - enable PIM SM or SM-DM on the multicast traffic path > >> > >> The first bullet maybe sounds strange, but that sentence I directly pulled >> out of Cisco 12.4T doc... > >> > >> Anyway, I tried various configs - using "ip pim ssm" everywhere for > >> instance, using variuos SSM JOINs, pinging with various sources... > >> Let's say > >> R1 will be the source, doing pings, and R2 makes the JOIN. And it all >> boils down to the following: > >> > >> > >> - it does not matter if I enable IGMP v3 at all on R2 (??) > >> > >> - it does not matter from which R1 interface I am doing the > >> pings > >> (???) - defeats the purpose of SSM... > >> > >> - the only thing that made a difference, meaning either > >> multicast works or not, is how I configure JOIN command on R2. The > >> only way the ping would work is if the source configured in the JOIN > >> command is the IP address of R1's interface CLOSEST TO R2 > >> > >> Example: > >> R1 and R2 are on an ethernet segment 10.10.12.0/24. I am doing JOIN on > >> R2 loopback, and I want the source to be R1 loopback... So, the > >> command on R2 is (besides the "ip pim ssm" of course) > >> > >> ip igmp join 232.0.0.1 source 1.1.1.1 > >> > >> And no matter what I do on R1, how I ping, it won't work. Not until I >> erase the previous command on R2 and enter: > >> > >> ip igmp join 232.0.0.1 source 10.10.12.1 > >> > >> As soon as I form the JOIN like this, everything works! And what is >> frustrating for me, even the ping from R1 loopback works - even if I >> strictly said I want the source from 10.10.12.1 .... > >> > >> Does this make any sense to you? The concept is so easy, few commands, but >> the practical side is killing me. Of course, there is no multicast filtering >> whatsoever. I repeat one more time, I was doing all combinations really, >> making various configs, but this is the only one that works. > >> > >> This is all done in dynamips, but I strongly think this is not some kind >> of a dyna-bug. Every time, during preparing for the exam, I thought that >> something does not work because of the dynamips - I was proven wrong later. > >> :) It was my lack of knowledge every single time. > >> > >> ? > >> > >> Best Regards, > >> > >> Bojan Zivancevic > >> Network Engineer > >> _______________________________________________ > >> For more information regarding industry leading CCIE Lab training, > >> please visit www.ipexpert.com > >> > >> _______________________________________________ > >> For more information regarding industry leading CCIE Lab training, > >> please visit www.ipexpert.com > >> _______________________________________________ For more information regarding industry leading CCIE Lab training, please visit www.ipexpert.com
