The blog doesn't seem to exist anymore but if anybody is maintaining this channel I just want them to know this series incredibly well done and the teacher is excellent.
Great content. Good to have a basic understanding of mcast and sparse mode before watching the video. Then, this video will take you to the next level. Thanks for the upload.
Super usefull video! Thank you very much for this. When watching your video I came out with the doubt about how R1 knows who the RP is (cause it needs to know the RP's IPto send the unicast message) but I found it quickly doing a google search (All routers are either pre-configured with the RP’s address or can earn it dynamically through Auto-RP or the BSR protocol) By now I will go with the fact all the routers are pre-configured with RP's address. Thanks again!
This is the best series ever. Multicast seemed like black magic before. I know this is an older series, but would you be interested in making videos about bidir, ssm, anycast rp, msdp an so on?
Awesome, thank you - however I would expected the presenter to go a bit further elaborating on SPT switchover - this is when the LHR has the capability to switch to the shortest path Tree and bypass the RP (if the traffic rate hits the threshold set) - building a new branch of the source tree (S,G) SPT. In the example given, there is no shortest path between FHR and LHR, maybe something to update - just a personal thought
Love this series. Quick question. Do interfaces remain in the OIL indefinitely after receiving the initial PIM Join? or do downstream routers need to send PIM Joins on a regular interval as a sort of 'keep alive' to remain in the OIL?
Mike Condon PIM is referred to as a Soft-State protocol which essentially means that all the states in PIM, including Joins and Registers must be refreshed periodically. PIM accomplishes this by associating a timer/timeout with each state. Thus, if a router stops receiving Join messages for a G on an interface in the OIL for a period exceeding the timeout, the interface is removed from the OIL. HTH.
Thanks for the good explanation. May I ask you a question? I have a streamer running on my router OS embedded. The stream is coming over the udp to the multicast address. When I route the stream to my internal router interface (where PC is connected) VLC is successfully connecting and playing video. But I need to stream outside and when I rout the stream to the external interface I see the multicast traffic running (with tcpdump), but my VLC on my local PC doesn't connect anymore. My provider told me they had IGMP and PIM set and running. Unfortunately I cant check the stream as I have no other available PC. And the VLC on the smartphone doesn't support udp routing. What I misunderstood? What am I doing wrong?
You are correct that in the example, with the placement of Source, Receiver and RP, you technically do not need to define an RP on R2. But think of a network that needs to scale, has built in redundancy and has multiple Sources and Receivers at various locations. In that network, it would be hard to determine which routers will need to have the RP defined and which ones do not. That is the reason for consistently defining a common RP across the whole MC domain.
This lecture could have been summarized to half of its duration. So much unbelievable amount of repeatition leading to a lot of frustration that otherwise could have been a superb effort. Anyways thanks for putting this up.
The blog doesn't seem to exist anymore but if anybody is maintaining this channel I just want them to know this series incredibly well done and the teacher is excellent.
Real great job with explaining the concepts! If only profs taught like you do
Great content. Good to have a basic understanding of mcast and sparse mode before watching the video. Then, this video will take you to the next level. Thanks for the upload.
Watched this after reading a guide for a cert. Have to say this was fantastic, very well presented and easy to understand, thank you!
you are the best when it comes to multicasting, I loved the lecture, you made it so simple, can you please make some videos on IPv6 also
Super usefull video! Thank you very much for this. When watching your video I came out with the doubt about how R1 knows who the RP is (cause it needs to know the RP's IPto send the unicast message) but I found it quickly doing a google search (All routers are either pre-configured with the RP’s address or can earn it dynamically through Auto-RP or the BSR protocol) By now I will go with the fact all the routers are pre-configured with RP's address. Thanks again!
First serie about Multicast worth watching. Thank you very much for dedicating your time to make videos like this one. Well explained!!
This is the best series ever. Multicast seemed like black magic before. I know this is an older series, but would you be interested in making videos about bidir, ssm, anycast rp, msdp an so on?
This is a fantastic tutorial organized and very well presented. I am wondering if the presentation slides are available for download.
Great Lectures!!! Great for refreshing for CCIE exam preps.
Awesome, this is Well simplified and easily digestible information.
Thank you for your kind words. I am glad you are finding the content useful.
Thanks for sharing Sr.
Great videos, thank you!
What if r7 wants to join the multicast tree. It's metric directly to FHR looks shorter than via RP
well presented, too good flow and very well articulated
Thanks for your explanation, i have question, why R5 didn't send IGMP register to RP ? why RP much prefer to use R6 as best path to RX ? thanks
Well-explained !
Awesome, thank you - however I would expected the presenter to go a bit further elaborating on SPT switchover - this is when the LHR has the capability to switch to the shortest path Tree and bypass the RP (if the traffic rate hits the threshold set) - building a new branch of the source tree (S,G) SPT. In the example given, there is no shortest path between FHR and LHR, maybe something to update - just a personal thought
Have you checked out czcams.com/video/SCVDPlmsl4g/video.html yet?
Really well put together lecture thank you for all your hard work.
Thank you for your kind words. I am glad you are finding the material useful.
"Time to grow up, you're not a normal router anymore". XD
P.S. Great lecture!
I am glad you are finding the content useful.
Great work .... highly appreciated ...
👍🏻
great keep on posting plz
great explanation!!
Love this series.
Quick question. Do interfaces remain in the OIL indefinitely after receiving the initial PIM Join? or do downstream routers need to send PIM Joins on a regular interval as a sort of 'keep alive' to remain in the OIL?
Mike Condon PIM is referred to as a Soft-State protocol which essentially means that all the states in PIM, including Joins and Registers must be refreshed periodically. PIM accomplishes this by associating a timer/timeout with each state. Thus, if a router stops receiving Join messages for a G on an interface in the OIL for a period exceeding the timeout, the interface is removed from the OIL.
HTH.
Thanks for the good explanation.
May I ask you a question?
I have a streamer running on my router OS embedded. The stream is coming over the udp to the multicast address.
When I route the stream to my internal router interface (where PC is connected) VLC is successfully connecting and playing video.
But I need to stream outside and when I rout the stream to the external interface I see the multicast traffic running (with tcpdump), but my VLC on my local PC doesn't connect anymore.
My provider told me they had IGMP and PIM set and running.
Unfortunately I cant check the stream as I have no other available PC. And the VLC on the smartphone doesn't support udp routing.
What I misunderstood? What am I doing wrong?
You mention all routers need to be configured with the same RP IP. in your example, why R2 needs to know the RP IP?
You are correct that in the example, with the placement of Source, Receiver and RP, you technically do not need to define an RP on R2.
But think of a network that needs to scale, has built in redundancy and has multiple Sources and Receivers at various locations. In that network, it would be hard to determine which routers will need to have the RP defined and which ones do not. That is the reason for consistently defining a common RP across the whole MC domain.
This lecture could have been summarized to half of its duration. So much unbelievable amount of repeatition leading to a lot of frustration that otherwise could have been a superb effort. Anyways thanks for putting this up.
That's why I watch at 2x or 1.5x the normal speed! :-)
there's an old saying in my country: "repeating is the mother of knowledge". you could've been grateful and keep this comment to yourself