This topic is to discuss the following lesson:
Great lesson, however I have a question about for the host don’t we need ip pim sparse-mode? I can see on the router we have ip pim sparse-mode.
PIM is only required on multicast routers. I’m using routers as hosts but the only thing they need is “igmp join” to simulate a host. There’s no need for multicast routing or PIM on these host routers.
with respect to below 2 statements: what is the diff between multicast-routing and PIM command ? both seems to be doing same thing - process the IGMP traffic.
1.First we enabled multicast routing globally, this is required for the router to process IGMP traffic.
2.We enabled PIM on the interface. PIM is used for multicast routing between routers and is also required for the router to process IGMP traffic.
a. from where .40 address came ? does router generates it randomly ?
b. group address 184.108.40.206 who decides and gives this IP in real time environment ?
Think of it as acting the same like a regular dynamic routing protocol. So, for example, you can enable EIGRP to run on a particular interface, but it won’t do anything unless you also turn on EIGRP to run globally. Likewise, you have to tell the router that you want it to route multicast traffic globally, but you also need to tell it which interfaces need to be listening for the multicast traffic.
Thx Andrew, got it now .
In your conclusion you mention “one of the downsides of IGMP version 1 is that the router will keep forwarding multicast traffic even when there are no more hosts interested in our traffic.”
Do you mean it will continue to send membership queries even though no host care to listen?
I am just trying to understand what “traffic” it will keep sending that makes version somewhat inefficient, thanks.
IGMP version 1 only had two messages: the membership query and membership reply. There was no message that allowed a host to inform that he didn’t want to receive multicast traffic for a certain group anymore. It was possible that a router would forward packets to a certain multicast group with no listeners anymore…
So with traffic, I meant the actual video/audio/application traffic for the multicast group that the listeners are interested in.
Rene, Good network article.
Need some clarification.
What are the IPs 220.127.116.11 and 18.104.22.168. Are these IPs default for Membership Report and Query process. Why the host need to join to 22.214.171.124 group, Is it the default group or global group for multicast? Can there be other group IPs can be configured?
Both of these addresses are multicast addresses, however each one is used for a different purpose. The 126.96.36.199 IP address is a well known multicast IP and it addresses all the hosts on a network segment. This is used when the router sends out the membership query because all hosts are asked if they are (still) interested in receiving the multicast traffic.
The 188.8.131.52 mutlicast IP address refers to a multicast group only. This is the IP address that corresponds ONLY to those hosts that have expressed interest in taking part in the specific group. This is the actual IP address which is used to send the multicast traffic to the hosts participating in the group.
I hope this has been helpful!
Let’s assume that there is no R1 , only two hosts connected to a switch in same vlan ,
What will happen in that case ?
R1#show ip igmp groups 184.108.40.206 IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter Group Accounted 220.127.116.11 GigabitEthernet0/1 19:22:56 00:01:07 192.168.1.101
Can you explain
Why the host cannot see 192.168.1.102 cant see here
If there is no router, IGMP version 1 will not function correctly. This is because the router is the one that manages the multicast membership of each host.
I hope this has been helpful.
Hello again Sims
There are several reasons why this would be the case:
- The IGMP join-group command may not be configured on H2
- There may be an IGMP version mismatch
- Make sure there is connectivity between H2 and the router
Try using some debug commands described in the lesson to see if there is an attempt to include the host in the group but there is some kind of error. The debugs should help you out there.
I hope this has been helpful!
How can I verify IP multicast-outing is enable or not by using show commands ?
There are two options that come to mind:
R1#show ip multicast Multicast Routing: enabled Multicast Multipath: disabled Multicast Route limit: No limit Multicast Triggered RPF check: enabled Multicast Fallback group mode: Sparse Multicast DVMRP Interoperability: disabled
Or just check the running config:
R1#show run | include multicast-routing ip multicast-routing
Thanks Rene your answer is helpful for me
Hi Larazos, Rene,
With regards to the Administratively-scoped (local) multicast addresses, am i right to say that we could select from the ranges below when assigning the multicast group address?
18.104.22.168 - 22.214.171.124
What is the exact rule for assigning the IP address for the multicast group?
Can we also select from the below addresses?
126.96.36.199 - 188.8.131.52 - Reserved for special “well-known” multicast addresses
224.01.0 - 184.108.40.206 - Globally-scoped
The 220.127.116.11 to 18.104.22.168 range of multicast IP addresses known as “Administratively scoped” addresses. These are defined by RFC 2365 and are reserved for private use within an organization. So to answer your question, yes, when configuring multicast groups it is best practice to use these addresses.
Having said that, as you probably know, there are various special-use multicast addresses that have various purposes as defined by the IANA and by various RFCs. Although I don’t like linking to Wikipedia, I find that their summary of the IPv4 multicast address groups is quite comprehensive and complete, and you can find it at the following link:
So can you use these other multicast addresses to define a multicast group? Well, yes, nothing stops you from doing that. However, if you overlap with various well known multicast addresses such as those used by OSPF or EIGRP, then this will result in the malfunctioning of any such routing protocols you may have running on your network.
Even though technically you can indeed configure them, practically, it can present a problem on your network.
I hope this has been helpful!