This is such an awesome series of videos. Finally got that 💡moment where it all suddenly makes sense. Thank you for taking the time to make these vids!
I had a problem in my network about 5 years ago now that made me switch from a Layer 2 to Layer 3 topology because I kept getting floods of packets that I could not understand. All these years later, I finally know that I had a multicast storm. This series has been pure gold!
My good man, thank you for making this motherload of invaluable information. It's a Saturday, and I am enjoying your hard work over a hot cup of coffee
No Comparisons,,, great session…thanks for your time and effort… Please provide session on other technologies like EVPN, Segment Routing, Inter AS options A, B & C, DNVPN, VXLAN, DCI etc… I am ready to pay…
Thank you very much for your awesome video on IGMP. A little detail that caught me last night, regarding time 42:45, isn't it better instead of using the term "cancel" any pending Reports to use the term "Report suppresion" keeping RFC 2236 Article 3. Protocol Description (tools.ietf.org/html/rfc2236) in mind ? Thank you and keep up the good work. Much appreciated!
I am glad you enjoyed the video. I do admit I have been a little liberal with the term there. You are absolutely correct that the term should be "report suppression". I am hoping the overall idea does go through and not ends up confusing people. Let me try to see if we can fix that via some clever annotation. Thanks again.
Not exactly. Unless until the switch has a physical loop unprotected by STP or another loop prevention mechanism, it is safe for Multicast. The switch will forward the packet to all port EXCEPT the one it was received on thereby ensuring no loops form under normal conditions. I am not sure which part of the lecture you are referring to but I can add that Multicast unaware switches treat Multicast as Broadcast thereby flooding the MC packets inside a VLAN, nullifying the whole advantage of Multicast over Broadcast. The packet reaches all hosts in the VLAN, even those that are not interested in the MC stream. HTH.
@@DecodingPackets so to avoid this flooding only igmp snooping helps, is my understanding correct ? if so as soon as we enable igmp snooping on switch this default flooding behaviour will stop ? but usually igmp snooping is enabled on vlans right. ? looking forward for your answer
Hi thanks for the amazing videos. I have a doubt, if you ping a multicast address how does the ping packet travel back to the source ? Is it unicasted back ? Does the receiver have to have the IP multicast routing command enabled ? I'm so confused with how the ping packet travels to and from the source and receiver. Sometimes I don't get ping replies but the multicast tree is correct and the receiver is recieving the pings. If you could clear this concept for me I would be very grateful.
The "ping reply" or ICMP echo-reply to be technically correct is, as you predicted, a unicast packet. So the destination IP of the echo-reply will be gleaned from the source IP or the multicast packet received and the source IP of the echo-reply will be a local IP address (exit interface or loopback). The receiver does not need the ip multicast-routing command on it but it needs to either have the routing information for the source IP of the multicast packet or have a default gateway that can route the echo-reply properly. If you see the multicast echos being received on the receiver (from debug ip mpacket or the new mrib command) and you still do not see successful pings on the source, then what you should look into the unicast routing from the receiver back to the source. HTH.
Thank you so much, that cleared up things for me. I have a couple of other doubts If I may ask. 1. What is the significance and purpose of the ip multicast routing command ? Does it tune the routers interface to listen to all multicast messages which it wasn't doing before ? 2. Does a host by default listen to all multicast streams on the LAN or only the streams which we have manually told it to receive by using the ip igmp join command ? 3.If we have a source and a receiver on the same LAN, do we need to have ip multicast routing command enabled on either of them ? will the multicast stream be received simply by telling the receiver to listen to a particular stream by using ip igmp join command and no other command ? 4. I read in Jef doyles routing tcp/ip volume 2 book about igmp selecting a querier in a segment, making it the designated router and in charge of forwarding the multicast session. PIM's assert mechanism also does this job, will they conflict each other ? If both mechanisms select a DR what happens if PIM's DR is different from IGMP's DR ? does one supercede the other ? You mentioned that IGMP version 1 needed this mechanism but is no longer required after PIM was introduced. Is this feature removed in IGMP V2 ? 5. Unicast load balancing is per flow basis. In multicasting what is the concept of load balancing ? 6.Can you please make a video on AutoRP and BSR ? Thank you so much once again !
1. What is the significance and purpose of the ip multicast routing command ? Does it tune the routers interface to listen to all multicast messages which it wasn't doing before ? Answer - Yes and no. The router's interfaces by default already listen to Link-local multicast messages (this relates to a later question you have). ip multicast routing directs the router to create an MRIB or Multicast State Table. This RIB is used to route multicast packets, i.e. allow multicast packets to transit the router. So without the command, the router can be both a source and a receiver but not a transit device. With the command, it creates the proper data structures to allow it to route multicast packets and act as a transit device. 2. Does a host by default listen to all multicast streams on the LAN or only the streams which we have manually told it to receive by using the ip igmp join command ? Answer - A host on a LAN will only listen to streams that it has been configured to receive. Now these may be configured (on an IOS host device) with the use of the ip igmp join command but they may also be configured via other means - e.g. enabling OSPF/EIGRP/PIM on an interface. Or configuring a multicast group for NTP. But the crux of the story is, the streams that the device listens to must be configured explicitly. 3.If we have a source and a receiver on the same LAN, do we need to have ip multicast routing command enabled on either of them ? will the multicast stream be received simply by telling the receiver to listen to a particular stream by using ip igmp join command and no other command ? Answer - This was touched in answer 1 and essentially the answer is no. For link-local or intra-VLAN or L2 multicast packets, ip multicast routing is not needed. You can use once again use any of the means to enable the device to receive multicast streams and ip igmp join will work. 4. I read in Jef doyles routing tcp/ip volume 2 book about igmp selecting a querier in a segment, making it the designated router and in charge of forwarding the multicast session. PIM's assert mechanism also does this job, will they conflict each other ? If both mechanisms select a DR what happens if PIM's DR is different from IGMP's DR ? does one supercede the other ? You mentioned that IGMP version 1 needed this mechanism but is no longer required after PIM was introduced. Is this feature removed in IGMP V2 ? Answer - PIM assert does not share any responsibilities with the IGMP querier. IGMP querier's sole goal (summary version) is to ascertain if there are any hosts on the network that are still interested in a particular MC stream. Now this may be a general query to check on all groups at once (v1 and v2) or a group specific query in response to a Leave message (v2 only). My videos discuss both of these in great detail. PIM assert on the other hand addresses an issue where multiple MC routers may send the same stream on the same L2 network because they are both attached to it. In this case, PIM assert messages allow the routers to elect one designated forwarder for the L2 network and the other routers prune the stream from their interface on the L2 link. This is usually seen in dense mode but under the right circumstances, can also be seen in Sparse mode. This mechanism is discussed in detail here - th-cam.com/video/9sNOiLjyPnk/w-d-xo.html PIM DR role is different than IGMP designated querier role although in IGMPv1, they are both played by the same router. This is because IGMPv1 lacks a mechanism to elect a DQ and simply selects the DR as the DQ. I already explained the DQ aspect in answer 4. The DR is responsible for for the PIM signaling upstream of the VLAN/L2 link. So if multiple MC routers on the same L2 link or VLAN all receive IGMP membership reports, to allow for loop prevention, only a single router should be signaling the report upstream to the MC routing protocol (PIM for all intents and purposes). So DR, in short is the MC router that is the only router that is allowed, on a VLAN to take an IGMP membership report and create a PIM join out of it. As you can see, a completely different purpose than the IGMP DQ. If you can send me the time stamp of what you are referring to, I can comment further but what I probably said was the same thing I wrote earlier. IGMPv1 did not have an election mechanism for DQ so it relied on the MC routing protocol to elect the DQ. IGMPv2 has a mechanism to elect its own DQ. But rest assured, all IGMP versions (1, 2 and 3) need a DQ. So one is always elected. 5. Unicast load balancing is per flow basis. In multicasting what is the concept of load balancing? Answer - Multicast uses load splitting instead of load balancing (www.cisco.com/c/en/us/td/docs/ios/12_4t/ip_mcast/configuration/guide/mctlsplt.html#wp1057306). It is still flow based in a sense but the flow now is the combination of (S or S,G). So if there are two possible RPF interfaces for a source, the router pseudorandomly picks one as the IIF for a given stream. This is the interface that is added to the MRIB and this is the interface/RPF neighbor that the PIM join is sent towards. 6.Can you please make a video on AutoRP and BSR ? Answer - We have BSR on the roadmap but probably not AutoRP (hopefully the reason there is obvious, HINT - This was written in 2018) :) HTH.
Wow Thank you so much for taking the time to answer my questions, that cleared things right up for me. The reason I was confused about IGMP having anything to do with the multicast forwarding session was because I read this in routing tcp/ip vol 2 by jef Doyle :- The routers are aware of each other because of their routing protocols. So one way to ensure that only one router forwards the session onto the subnet is to add a designated router, or querier, function to the multicast routing protocol. The querier is responsible for forwarding the multicast stream. The other router or routers only listen, and they begin forwarding the stream only if the querier fails. The problem with allowing the routing protocol to elect a querier is that multiple IP multicast routing protocols are available. If the two routers in Figure 5-10 (Figure shows 2 routers forwarding a multicast session to the same LAN ) are running incompatible protocols, their respective querier election processes will not detect each other; each will decide that it is the querier, and both will forward the data stream. The local group management protocol, however, is independent of the routing protocols. The routers have to run this common protocol to query group members, so it makes sense to give the querier function to the group management protocol. This guarantees that the routers are speaking a common language on the subnet and can agree on which is responsible for forwarding the session. Alas AutoRP is in the CCIE R&S Lab blueprint :/ Have a great day Nic
I can see why that might be confusing. Hopefully now you have a much better grasp of it. What has changed since the days that book was written is that PIM now is the de facto standard for MC routing protocol and IGMP the same for group management. So we can use these terms within the context of PIM and IGMP and not in a broader sense as the book is doing which makes life easier. My personal opinion, Auto-RP should be removed from the blueprint :)
this is absolutely phenomenal, the whole series is GOLD
Multicast has never been so clear, Thanks a lot
Thank you for your kind words.
This is such an awesome series of videos. Finally got that 💡moment where it all suddenly makes sense. Thank you for taking the time to make these vids!
You are very welcome. I am glad you are finding the videos useful. Thank you for your kind words.
I had a problem in my network about 5 years ago now that made me switch from a Layer 2 to Layer 3 topology because I kept getting floods of packets that I could not understand. All these years later, I finally know that I had a multicast storm. This series has been pure gold!
Great lecture. Very well laid out. I would like to add myself to the list of people wanting to see IGMP snooping lecture(s) too.
My good man, thank you for making this motherload of invaluable information. It's a Saturday, and I am enjoying your hard work over a hot cup of coffee
Great explanation...thank you so much for posting this.
This is better than anything you’d pay for on Udemy or another similar site, thank you!
Excellent, no words
I finally came across some pretty lectures regarding networking, i hoping you will entertain with other networking concepts
This is a great series on Multicast! I am thoroughly enjoying it! Thank you...
No Comparisons,,, great session…thanks for your time and effort…
Please provide session on other technologies like EVPN, Segment Routing, Inter AS options A, B & C, DNVPN, VXLAN, DCI etc…
I am ready to pay…
really helpful
Great Videos. We need IGMP Snooping Video. Are you planning to do this?
Thanks for sharing!
These videos are so nice explained. Any chance for new content? I see that the last video was 3 years ago
Thank you very much for your awesome video on IGMP.
A little detail that caught me last night, regarding time 42:45, isn't it better instead of using the term "cancel" any pending
Reports to use the term "Report suppresion" keeping RFC 2236 Article 3. Protocol Description
(tools.ietf.org/html/rfc2236) in mind ?
Thank you and keep up the good work.
Much appreciated!
I am glad you enjoyed the video. I do admit I have been a little liberal with the term there. You are absolutely correct that the term should be "report suppression".
I am hoping the overall idea does go through and not ends up confusing people. Let me try to see if we can fix that via some clever annotation. Thanks again.
Take a look again Stefan. You cannot see it on mobile platforms but that is a limitation of the TH-cam platform. Thanks again.
Plz make a series on QOS i really need it
There are no immediate plans for QoS but it is definitely a topic we intend to cover sometime in the future.
As I understand from Lecture 2, switches that are unaware of multicast are dangerous because they won't check the IIF (loops) ?
Not exactly. Unless until the switch has a physical loop unprotected by STP or another loop prevention mechanism, it is safe for Multicast. The switch will forward the packet to all port EXCEPT the one it was received on thereby ensuring no loops form under normal conditions.
I am not sure which part of the lecture you are referring to but I can add that Multicast unaware switches treat Multicast as Broadcast thereby flooding the MC packets inside a VLAN, nullifying the whole advantage of Multicast over Broadcast. The packet reaches all hosts in the VLAN, even those that are not interested in the MC stream. HTH.
@@DecodingPackets thanks a lot for your detailed explanation, that makes sense
@@DecodingPackets so to avoid this flooding only igmp snooping helps, is my understanding correct ? if so as soon as we enable igmp snooping on switch this default flooding behaviour will stop ? but usually igmp snooping is enabled on vlans right. ? looking forward for your answer
Hi thanks for the amazing videos. I have a doubt, if you ping a multicast address how does the ping packet travel back to the source ? Is it unicasted back ? Does the receiver have to have the IP multicast routing command enabled ? I'm so confused with how the ping packet travels to and from the source and receiver. Sometimes I don't get ping replies but the multicast tree is correct and the receiver is recieving the pings. If you could clear this concept for me I would be very grateful.
The "ping reply" or ICMP echo-reply to be technically correct is, as you predicted, a unicast packet. So the destination IP of the echo-reply will be gleaned from the source IP or the multicast packet received and the source IP of the echo-reply will be a local IP address (exit interface or loopback).
The receiver does not need the ip multicast-routing command on it but it needs to either have the routing information for the source IP of the multicast packet or have a default gateway that can route the echo-reply properly.
If you see the multicast echos being received on the receiver (from debug ip mpacket or the new mrib command) and you still do not see successful pings on the source, then what you should look into the unicast routing from the receiver back to the source.
HTH.
Thank you so much, that cleared up things for me. I have a couple of other doubts If I may ask.
1. What is the significance and purpose of the ip multicast routing command ?
Does it tune the routers interface to listen to all multicast messages which it wasn't doing before ?
2. Does a host by default listen to all multicast streams on the LAN or only the streams which we have manually told it to receive by using the ip igmp join command ?
3.If we have a source and a receiver on the same LAN, do we need to have ip multicast routing command enabled on either of them ? will the multicast stream be received simply by telling the receiver to listen to a particular stream by using ip igmp join command and no other command ?
4. I read in Jef doyles routing tcp/ip volume 2 book about igmp selecting a querier in a segment, making it the designated router and in charge of forwarding the multicast session. PIM's assert mechanism also does this job, will they conflict each other ? If both mechanisms select a DR what happens if PIM's DR is different from IGMP's DR ? does one supercede the other ? You mentioned that IGMP version 1 needed this mechanism but is no longer required after PIM was introduced. Is this feature removed in IGMP V2 ?
5. Unicast load balancing is per flow basis. In multicasting what is the concept of load balancing ?
6.Can you please make a video on AutoRP and BSR ?
Thank you so much once again !
1. What is the significance and purpose of the ip multicast routing command ?
Does it tune the routers interface to listen to all multicast messages which it wasn't doing before ?
Answer - Yes and no. The router's interfaces by default already listen to Link-local multicast messages (this relates to a later question you have). ip multicast routing directs the router to create an MRIB or Multicast State Table. This RIB is used to route multicast packets, i.e. allow multicast packets to transit the router. So without the command, the router can be both a source and a receiver but not a transit device. With the command, it creates the proper data structures to allow it to route multicast packets and act as a transit device.
2. Does a host by default listen to all multicast streams on the LAN or only the streams which we have manually told it to receive by using the ip igmp join command ?
Answer - A host on a LAN will only listen to streams that it has been configured to receive. Now these may be configured (on an IOS host device) with the use of the ip igmp join command but they may also be configured via other means - e.g. enabling OSPF/EIGRP/PIM on an interface. Or configuring a multicast group for NTP. But the crux of the story is, the streams that the device listens to must be configured explicitly.
3.If we have a source and a receiver on the same LAN, do we need to have ip multicast routing command enabled on either of them ? will the multicast stream be received simply by telling the receiver to listen to a particular stream by using ip igmp join command and no other command ?
Answer - This was touched in answer 1 and essentially the answer is no. For link-local or intra-VLAN or L2 multicast packets, ip multicast routing is not needed. You can use once again use any of the means to enable the device to receive multicast streams and ip igmp join will work.
4. I read in Jef doyles routing tcp/ip volume 2 book about igmp selecting a querier in a segment, making it the designated router and in charge of forwarding the multicast session. PIM's assert mechanism also does this job, will they conflict each other ? If both mechanisms select a DR what happens if PIM's DR is different from IGMP's DR ? does one supercede the other ? You mentioned that IGMP version 1 needed this mechanism but is no longer required after PIM was introduced. Is this feature removed in IGMP V2 ?
Answer - PIM assert does not share any responsibilities with the IGMP querier. IGMP querier's sole goal (summary version) is to ascertain if there are any hosts on the network that are still interested in a particular MC stream. Now this may be a general query to check on all groups at once (v1 and v2) or a group specific query in response to a Leave message (v2 only). My videos discuss both of these in great detail.
PIM assert on the other hand addresses an issue where multiple MC routers may send the same stream on the same L2 network because they are both attached to it. In this case, PIM assert messages allow the routers to elect one designated forwarder for the L2 network and the other routers prune the stream from their interface on the L2 link. This is usually seen in dense mode but under the right circumstances, can also be seen in Sparse mode. This mechanism is discussed in detail here - th-cam.com/video/9sNOiLjyPnk/w-d-xo.html
PIM DR role is different than IGMP designated querier role although in IGMPv1, they are both played by the same router. This is because IGMPv1 lacks a mechanism to elect a DQ and simply selects the DR as the DQ. I already explained the DQ aspect in answer 4.
The DR is responsible for for the PIM signaling upstream of the VLAN/L2 link. So if multiple MC routers on the same L2 link or VLAN all receive IGMP membership reports, to allow for loop prevention, only a single router should be signaling the report upstream to the MC routing protocol (PIM for all intents and purposes). So DR, in short is the MC router that is the only router that is allowed, on a VLAN to take an IGMP membership report and create a PIM join out of it. As you can see, a completely different purpose than the IGMP DQ.
If you can send me the time stamp of what you are referring to, I can comment further but what I probably said was the same thing I wrote earlier. IGMPv1 did not have an election mechanism for DQ so it relied on the MC routing protocol to elect the DQ. IGMPv2 has a mechanism to elect its own DQ. But rest assured, all IGMP versions (1, 2 and 3) need a DQ. So one is always elected.
5. Unicast load balancing is per flow basis. In multicasting what is the concept of load balancing?
Answer - Multicast uses load splitting instead of load balancing (www.cisco.com/c/en/us/td/docs/ios/12_4t/ip_mcast/configuration/guide/mctlsplt.html#wp1057306). It is still flow based in a sense but the flow now is the combination of (S or S,G). So if there are two possible RPF interfaces for a source, the router pseudorandomly picks one as the IIF for a given stream. This is the interface that is added to the MRIB and this is the interface/RPF neighbor that the PIM join is sent towards.
6.Can you please make a video on AutoRP and BSR ?
Answer - We have BSR on the roadmap but probably not AutoRP (hopefully the reason there is obvious, HINT - This was written in 2018) :)
HTH.
Wow Thank you so much for taking the time to answer my questions, that cleared things right up for me.
The reason I was confused about IGMP having anything to do with the multicast forwarding session was because I read this in routing tcp/ip vol 2 by jef Doyle :-
The routers are aware of each other because of their routing protocols. So one way to ensure that
only one router forwards the session onto the subnet is to add a designated router, or querier,
function to the multicast routing protocol. The querier is responsible for forwarding the multicast
stream. The other router or routers only listen, and they begin forwarding the stream only if the
querier fails.
The problem with allowing the routing protocol to elect a querier is that multiple IP multicast routing
protocols are available. If the two routers in Figure 5-10 (Figure shows 2 routers forwarding a multicast session to the same LAN ) are running incompatible protocols, their
respective querier election processes will not detect each other; each will decide that it is the querier,
and both will forward the data stream.
The local group management protocol, however, is independent of the routing protocols. The routers
have to run this common protocol to query group members, so it makes sense to give the querier
function to the group management protocol. This guarantees that the routers are speaking a common
language on the subnet and can agree on which is responsible for forwarding the session.
Alas AutoRP is in the CCIE R&S Lab blueprint :/
Have a great day Nic
I can see why that might be confusing. Hopefully now you have a much better grasp of it. What has changed since the days that book was written is that PIM now is the de facto standard for MC routing protocol and IGMP the same for group management. So we can use these terms within the context of PIM and IGMP and not in a broader sense as the book is doing which makes life easier.
My personal opinion, Auto-RP should be removed from the blueprint :)
Great!!!
can you upload the slides ?
completed again while logged under work ID in this time
I do hope it was work related. I mean it is not the most interesting of topics for general viewing. :)