Multicast Routing Protocol IGMP learning notes

Source: Internet
Author: User

Multicast

Unlike the one-to-one transmission over the network, it is a one-to-many (at least one) point based on UDP/IP point transmission protocol,

The multicast router uses the IGMP protocol to check whether the multicast group receiver exists in the network segment connected to each interface, that is, the group members. If a member exists, the multicast router should forward the multicast packet to This CIDR block. If no member exists, stop forwarding.

For details, refer

Http://www.networksorcery.com/enp/protocol/igmp.htm

 

Multicast
The destination address of the packet uses a Class d ip address, ranging from 224.0.0.0 to 239.255.255.255.

 

 

* The host reports the desired group to the multicast router through the IGMP protocol.
* The vro uses the IGMP protocol to check whether there are Members in a specific group in the CIDR block.

There are many concepts on the Internet. This article mainly describes the protocol from the perspective of a host.

 

So far, there have been a total of four versions, and version 0 is basically no longer used by people. The first version is introduced in detail, and the last two or three versions have added a few features on version 1.

Current igmp3 versions:
RFC1112-IGMP version 1
RFC2236-IGMP Version 2
RFC3376-IGMP Version 3

 

* Member joining process

When a host joins a new group, it shocould immediately transmit a report
For that group,
Rather than waiting for a query, in case it is the first member of that
Group on the network.
To cover the possibility of the initial report being lost or damaged,
It is
Recommended that it be repeated once or twice after short delays.
A simple way to accomplish this is to act as if a query had been
Initialized ed for that group only, setting the group's random report delay
Timer.

============================

When a host wants to join a multicast, it must immediately send a report to the multicast instead of waiting for the route point to query information, to avoid this situation (the host is the first host to be added to the multicast ). To ensure that the host reports are lost or damaged, it must be repeated once or twice (each time there is a short interval) it is not until you receive the route point query information that the multicast has been successfully run. Then, the host can reset a random countdown timer to prepare a report for sending (see the following for details)

 

,

* Route Query

Routers periodically sendIGMP host Membership Queries
To the all-hosts
Group (224.0.0.1) with a TTL of 1 (once every minute or two). All
Multicast-capable hosts hear them,
But don't answer immediately to avoid an IGMP host membership report storm.
Instead, they start a random delay timer for each group they belong
On the interface
They has ed the query.

Sooner or later, the timer expires in one of the hosts, and it sends
IGMPHost membership report
(Also with TTL 1) to the multicast address of
Group being reported. As it is sent to the group, all hosts that joined
The group-and which are currently waiting for their own timer to expire-
Receive it, too. Then, they stop their timers and don't generate any other
Report. Just one is generated-by the host that chose the smaller timeout -,
And that is enough for the router. It only needs to know that there are
Members for that group in the subnet, not how many nor which.

When no reports are attached ed for a given group after a certain number
Of queries, the router assumes that no members are left, and thus it
Doesn't have to forward traffic for that Group on that subnet. Note that
In igmpv1 there are no "Leave Group messages ".

========================

Vrortrta periodically sends member relationship query information to all hosts in the subnet (224.0.0.1 represents all hosts in the subnet. (A Query package with TTL = 1)

At the same time, all hosts that receive the query information point immediately start a countdown timer (which is generated randomly in a short time). When the first host (the countdown timer first goes) the host sends the igmpv1 member relationship report (TTL = 1) to the multicast group, and the host stops counting down immediately after receiving the report at another countdown point, you no longer need to send a link report to the router. Because the router sends a query packet to check whether the multicast CIDR block still exists on the host, it is sufficient to receive a reply, it does not need to know who or how many hosts are playing in this group. Of course, if the router does not receive any reply after sending the query packet several times, it considers that all the hosts of the multicast have left silently, and it will reclaim the network segment. Note: If the host does not exist in version 1, click "Leave Group messages"

 

 

 

Appendix:

224.0.0.0 ~ 224.0.0.255 is the reserved multicast address (Permanent Group address). The address 224.0.0.0 is retained without allocation. Other addresses are used by the routing protocol;

224.0.1.0 ~ 224.0.1.255 is a public multicast address and can be used on the Internet;

224.0.2.0 ~ 238.00000000255 is the user's available multicast address (temporary group address), which is valid across the network;

239.0.0.0 ~ 239.00000000255 is the multicast address of the Local Management Group. It is valid only for a specific local range.


Reserved multicast addresses

The list is as follows:
  

224.0.0.0 base address (retained)

224.0.0.1 addresses of all hosts (including all Routers
Address)

224.0.0.2 addresses of all multicast routers

224.0.0.3 not allocated

224.0.0.4 dvmrp Router

224.0.0.5 OSPF Router

224.0.0.6 OSPF Dr

224.0.0.7 st Router

224.0.0.8 st host

224.0.0.9 rip-2 Router

224.0.0.10

224.0.0.11 activity proxy

224.0.0.12 DHCP server/relay proxy

224.0.0.13 all PIM Routers

224.0.0.14 RSVP Encapsulation

224.0.0.15 all CBT Routers

224.0.0.16 specify SBM

224.0.0.17 all sbms

224.0.0.18 vrrp

 

See.

Protocol Interpretation

Http://www.ibiblio.org/pub/Linux/docs/howto/other-formats/html_single/Multicast-HOWTO.html#s6

 

Protocol packet format

Http://www.networksorcery.com/enp/protocol/igmp.htm

 

Detailed multicast addresses for each group:

Http://www.networksorcery.com/enp/protocol/ip/multicast.htm

 

 

 

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.