Great, great lectures! I have just finished this whole series of videos, and now I have a completely new understanding of multicast. I can imagine how much time and effort you have spend on this series, just want to say THANK YOU, GREAT WORK!
i would like to say Thank you!! this is absolutly the best series on Multicast , so much detailed and everything makes absolute sense here. a lot of things which were incorrect to my knowledge has been cleared now . thank you and a big Fan of Yours. hope to know your name Sir , so i can follow you!!
Thank you so much for the multicast series. It really helped me to get a good understanding on multicast protocols. I am looking forward to learn more protocols using this channel.
Watched the entire series. I am an ex Cisco TAC engineer for LAN/Routing teams and i must say i have never seen such a video on multicast making it so simple to understand....It was always a scary protocol for me :), Thanks a lot Decoding Packets (Dont know your name ;)) for your time/efforts. Any plans to make video on SD Access?
This video is just amazing, even though the topic is so complex and difficult you provided a good explanation. Definitely the use of the topology ease things. THANKS!
Its a greatest lecture i ever seen...Thank you. It would be great if u please expalin about AnycastRP/AutoRP and MSDP as well. Thanks again for great lectures.
Great Lecture ! Thanks for your time and Effort. The Exact question which I had on this section is also got discussed/answered in the comments section :-)
Thank you for your kind words. Lively comment sections can be extremely useful especially for complex techs such as Multicast. Glad you found your answer there.
Greatly simplified by diagrams and step-by-step learning. Thanks a lot! Do you also happen to have any existing or upcoming videos about anycast RP and MSDP? That'll help very much, thanks again.
Thanks Dhaval. We are working on those two topics as part of the IP Multicast Lecture Series (ua-cam.com/video/fRiOOWJDcK8/v-deo.html) and should have an update in the near future. The channel has been on a short hiatus and will return soon to complete this series. I would suggest subscribing if you have not already to get notified about the uploaded videos automatically.
Amazing information. One question, when the R3 sends MC traffic towards R4 on the (*,G) tree, when R4 receives the MC traffic, why does it not automatically start building its own (S,G) tree instead of it waiting for R6 to send the (S,G) Join message?
OK I think writing that message is what it took for me to realize the answer...in the real world, R4 may not actually be on the SPT, so it is best for it to not trigger the creation of a (S,G) until a join request is received. If a Join request is received, it then knows it is part of the SPT for some one, and then creates the state/OIL/IIF
If there is another router between R3 and R4(say R10) and has a receiver connected which is interested in the same (S,G) will the R10 still forward the S,G,RPT purne towards RP? And one more thing if R4 is BP is and it received 2 streams of traffic the stream from (*,G) should fail since the S,G for the packets has a different IIF and packets could be dropped. Can this make S,G,RPT purne redundent?
great lectures! I have a question regarding switchover. If there was another MHR between R3 and R4, lets say R34, and SPT switchover process caused R4 to send a (S,G,RPT) Prune towards R3 via R34, but there was another receiver connected to R34 which SPT goes via RP, will this very special Prune cause removal of interface between R34 and R4 from both (*,G) and (S,G) trees OILs on R34?
It would not. Remember, the PIM states, Joins and Prunes are all relevant per-interface and not for a device as a whole. So what will happen is the R34 interface facing R4 which receives the prune will prune the interface from the S,G tree which is what R4 desired. But at the same time, for the locally connected receiver, R34 will still maintain an S,G tree towards the RP and in fact the RP will not prune itself off the S,G tree as well which what one might expect. So the final effect is that the S,G tree exists from S to FHR to RP to R34 but not down to R4. Let me know if that answers your question.
Hi, I also would like to thank you VERY much for this awesome series. But I do have a follow up question on the above. As I understood, this special prune message will only be processed by the RP (bring R3 in our case), so how come R34 is the one reacting to this prune message and prunning the interface towards R4? I would expect that R3 to receive this prune and react based on it. But in this case, it will create a problem for the receivers on the R34 router, so I don't know how this is handled or I might have misundertood something :]
One thing to remember is that PIM is a “soft-state” protocol so most messages (register being an exception) have to be processed by all PIM aware routers. Therefore the S,G,RPT message is processed not only by the RP but also by each MHR on the *,G, which means each router between the RP and the LHR. R34 has to process this message in order for R4 to successfully perform SPT switchover. Normally, with a single LHR (e.g R4 in our case) R34’s role is straightforward - prune the interface receiving the prune and forward the prune towards the RP. But in this case, R34 has another interface that needs the S,G stream and it’s path is via the RP. So R34 prunes the interface towards R4 as expected but after that is done, remember the OIL will not be empty, since there is still a local receiver left. In this case, since the OIL has interface(s) in it, the prune is not forwarded and that is the end of the line for it. Let me know if it makes sense. If it does not gel, try to draw it out. If still confused let me know specifically and I will try to clarify. Thanks!
you did fantastic job, but I am bored of these packet structure, I feel these packets keeps on repeating, but yes, the speed and delivery was exceptional,
Great, great lectures! I have just finished this whole series of videos, and now I have a completely new understanding of multicast. I can imagine how much time and effort you have spend on this series, just want to say THANK YOU, GREAT WORK!
I am CCIE but not fully understood Multicast. I'd like to say that this is the best Multicast course I have ever learnt. Thank you very much!!!
Best multicast technical lectures I have ever watched. Wonderful if there is similar series for other topics as BGP, OSPF, MPLS , Q and Q tunnelling.
i would like to say Thank you!! this is absolutly the best series on Multicast , so much detailed and everything makes absolute sense here. a lot of things which were incorrect to my knowledge has been cleared now . thank you and a big Fan of Yours. hope to know your name Sir , so i can follow you!!
WOW you make multicast so easy and interesting. Appreciate if you can make this kind of vides on all types of network technologies.
Thank you so much for the multicast series. It really helped me to get a good understanding on multicast protocols. I am looking forward to learn more protocols using this channel.
Very very good. Really complex concepts explained in simple language. Looking forward to other technologies
Thank you for your kind words. We are working towards adding some more videos soon.
Thank you very much for all this multicast serie. It was everything i needed to get into this matter for my work. Really clean explanation.
Watched the entire series. I am an ex Cisco TAC engineer for LAN/Routing teams and i must say i have never seen such a video on multicast making it so simple to understand....It was always a scary protocol for me :), Thanks a lot Decoding Packets (Dont know your name ;)) for your time/efforts. Any plans to make video on SD Access?
One of the best online youtube technical lectures I have ever watched. Really waiting for more videos covering more topics.
This video is just amazing, even though the topic is so complex and difficult you provided a good explanation. Definitely the use of the topology ease things. THANKS!
Its a greatest lecture i ever seen...Thank you.
It would be great if u please expalin about AnycastRP/AutoRP and MSDP as well.
Thanks again for great lectures.
Thank you again for this series!
Really
love the lectures!
One of the best youtube video to explain SPT switchover! Thank You!
You are very welcome. I am glad you are finding the content useful.
Great Lecture ! Thanks for your time and Effort. The Exact question which I had on this section is also got discussed/answered in the comments section :-)
Thank you for your kind words. Lively comment sections can be extremely useful especially for complex techs such as Multicast. Glad you found your answer there.
thanks for the material, I have nothing to say but keep up with the good work!
thank you very much for your excellent videos. Very well structured and delivered material, this has helped me greatly. Thank you again.
Thank you for your kind words. Glad you are finding the content useful.
Thanks for making this ...
You made it so easy to understand. THANK YOU
Thank you for you kind words. I am glad you are finding the content useful.
great videos, please keep it up!
Greatly simplified by diagrams and step-by-step learning. Thanks a lot! Do you also happen to have any existing or upcoming videos about anycast RP and MSDP? That'll help very much, thanks again.
Thanks Dhaval. We are working on those two topics as part of the IP Multicast Lecture Series (ua-cam.com/video/fRiOOWJDcK8/v-deo.html) and should have an update in the near future.
The channel has been on a short hiatus and will return soon to complete this series. I would suggest subscribing if you have not already to get notified about the uploaded videos automatically.
Excellent IP multicast training. Wonder where one can get the slides for the whole series of lectures.
Amazing information. One question, when the R3 sends MC traffic towards R4 on the (*,G) tree, when R4 receives the MC traffic, why does it not automatically start building its own (S,G) tree instead of it waiting for R6 to send the (S,G) Join message?
OK I think writing that message is what it took for me to realize the answer...in the real world, R4 may not actually be on the SPT, so it is best for it to not trigger the creation of a (S,G) until a join request is received. If a Join request is received, it then knows it is part of the SPT for some one, and then creates the state/OIL/IIF
this it's beautiful
Thank you for the kind words. It has not been called that before. :)
If there is another router between R3 and R4(say R10) and has a receiver connected which is interested in the same (S,G) will the R10 still forward the S,G,RPT purne towards RP? And one more thing if R4 is BP is and it received 2 streams of traffic the stream from (*,G) should fail since the S,G for the packets has a different IIF and packets could be dropped. Can this make S,G,RPT purne redundent?
Great !!
Great
great lectures!
I have a question regarding switchover. If there was another MHR between R3 and R4, lets say R34, and SPT switchover process caused R4 to send a (S,G,RPT) Prune towards R3 via R34, but there was another receiver connected to R34 which SPT goes via RP, will this very special Prune cause removal of interface between R34 and R4 from both (*,G) and (S,G) trees OILs on R34?
It would not. Remember, the PIM states, Joins and Prunes are all relevant per-interface and not for a device as a whole. So what will happen is the R34 interface facing R4 which receives the prune will prune the interface from the S,G tree which is what R4 desired. But at the same time, for the locally connected receiver, R34 will still maintain an S,G tree towards the RP and in fact the RP will not prune itself off the S,G tree as well which what one might expect.
So the final effect is that the S,G tree exists from S to FHR to RP to R34 but not down to R4.
Let me know if that answers your question.
hi! Thank you for answering this question! Yes, it does!
You are very welcome.
Hi, I also would like to thank you VERY much for this awesome series.
But I do have a follow up question on the above. As I understood, this special prune message will only be processed by the RP (bring R3 in our case), so how come R34 is the one reacting to this prune message and prunning the interface towards R4?
I would expect that R3 to receive this prune and react based on it. But in this case, it will create a problem for the receivers on the R34 router, so I don't know how this is handled or I might have misundertood something :]
One thing to remember is that PIM is a “soft-state” protocol so most messages (register being an exception) have to be processed by all PIM aware routers. Therefore the S,G,RPT message is processed not only by the RP but also by each MHR on the *,G, which means each router between the RP and the LHR.
R34 has to process this message in order for R4 to successfully perform SPT switchover. Normally, with a single LHR (e.g R4 in our case) R34’s role is straightforward - prune the interface receiving the prune and forward the prune towards the RP. But in this case, R34 has another interface that needs the S,G stream and it’s path is via the RP. So R34 prunes the interface towards R4 as expected but after that is done, remember the OIL will not be empty, since there is still a local receiver left. In this case, since the OIL has interface(s) in it, the prune is not forwarded and that is the end of the line for it.
Let me know if it makes sense. If it does not gel, try to draw it out. If still confused let me know specifically and I will try to clarify. Thanks!
you did fantastic job, but I am bored of these packet structure, I feel these packets keeps on repeating, but yes, the speed and delivery was exceptional,
Juuu