Geekly Articles each Day
📜 ⬆️ ⬇️

Optimizing multicast traffic on a local network using IGMP snooping



Hello! Today I would like to touch on the topic of multicast traffic transmission in a local corporate network, namely the work of IGMP snooping technology on switches. It so happened that in the last week several people addressed me with questions about this technology. And I decided to prepare a short article describing this technology. But in the process of preparation, it turned out that one cannot get away with brevity here, since there is something to write about. Who is interested in the question of IGMP snooping, welcome under cat.

Quite often, we don’t think much about how multicast traffic is transmitted within our L2 domain of the corporate network. Let me remind you that multicast traffic (also known as “multicast traffic”) is intended for transmitting data to a specific group of devices. By default, the switch transmits multicast traffic as broadcast (broadcast), i.e. to all ports without exception. This is because in the multicast packet, the recipient’s MAC address is a specially-formed address that does not belong to anyone on the network. If there is not a lot of multicast traffic, this does not create major problems and, more often, the administrator does not take any measures to optimize its transmission. If there is a lot of such traffic or you just want to “comb” the network, the challenge is to limit its distribution. Here come to the aid of various technologies to optimize the transfer of multicast traffic at the data link layer (IGMP snooping, CGMP, etc.). The most common and multi-vendor technology is IGMP snooping. IGMP snooping on many devices is enabled by default. For example, this is true for Cisco switches. But as often happens, happiness from the box can not get in all cases. The included IGMP snooping does not always give the expected result and multicast traffic in some cases for some reason continues to flow from all ports. Let's try to figure it out.
')
Start with the abbreviation IGMP. We all know that when a device appears on the network that wants to receive certain multicast traffic, this device reports its desire using Internet Group Management Protocol (IGMP). On many devices, IGMP version 2 is used by default. Message exchange of this protocol in the simplest case looks like this:

  1. The device, when it decides to receive multicast traffic, sends its request in the message IGMP Membership Report (hereinafter referred to as IGMP Report). It indicates what the device wants to receive. The address of the requested multicast group is specified as the destination IP address. This message is primarily intended for the nearest router. After all, it is he who is responsible for transmitting traffic between the local segment and the rest of the network.

  2. Having received such a message, the router starts to broadcast the requested multicast traffic to this network segment. Of course, this happens on condition that the router itself participates in the transmission of multicast traffic and receives the necessary traffic.

  3. To be sure that there are still multicast traffic recipients on the network, the router periodically sends an IGMP General Membership Query message (hereinafter referred to as IGMP General Query). After all, if no one is already there, why bother to “litter” this network segment with unnecessary traffic.

  4. In response to the IGMP General Query, the router receives an IGMP Report . It is usually sent by one of the recipients of multicast traffic. The others, having heard this message, simply keep silent, since one confirmation for each group is sufficient. The choice of who will respond to the router is implemented through the Report Suppression mechanism.

    Report Suppression
    If we have a lot of recipients of multicast traffic on the network, their responses to IGMP General Query can generate quite a large number of IGMP Report messages. Since the router only needs to receive one such message, the following optimization mechanism is used. The IGMP General Query message indicates the maximum time (Maximum Response Time - MRT) during which the router waits for a response. The client, having received IGMP General Query, selects an arbitrary timer value from 0 to MRT. As soon as the selected timer expires, the client sends an IGMP Report. This happens only if the client has not received the IGMP Report from any other recipient before.

  5. When a device no longer wants to receive multicast traffic for a specific group, it sends an IGMP Leave message.

  6. To this, the router responds with an IGMP Membership Group-Specific Query (IGMP Group-Specific Query), specifying whether there are any other devices on the network that want to receive traffic for this group. Usually, the router sends two messages. If there are such devices on the network, they will respond. If not, the router will stop broadcasting traffic to the local network segment.

In more detail about the operation of the IGMP protocol, and in general, multicast traffic can be read, for example, in a series of network articles for the smallest .

Since all IGMP messages pass through the switch, it could analyze them in order to determine which ports are the recipients of multicast traffic. And further, based on this information, transfer traffic only where it is needed. Actually, this is exactly what the IGMP snooping technology does.

The implementation of IGMP snooping from different manufacturers of network equipment in some nuances may be different. But in general, the scheme of work is similar. I suggest in general terms to consider its work on the example of Cisco switches. Next we look at the whole process in more detail:

  1. The first thing the switch does is determine where the router (s) is located. To do this, he listens to the presence of IGMP General Query, PIM, DVMRP, etc. messages on the network.

  2. The device sends an IGMP Report when it wants to receive this or that multicast traffic. This message intercepts the switch. From it, the switch receives the following information: a device with such a MAC address located behind a specific port wants to receive traffic from such a multicast group. Moreover, for the switch, when identifying a multicast group, the first thing that matters is not the IP address of this group (the IP addresses of multicast groups are in the range 224.0.0.0 - 239.255.255.255), but its MAC address. It is easier for the switch to work with addressing at the data link level. As we know, the MAC address is formed according to a certain rule from the IP address of the multicast group. All this information is stored in the switch MAC address table.

    Next, the switch sends to the side of the IGMP Report router, containing the same information as was received from the device.

  3. The router, upon receiving the IGMP Report message, starts sending multicast traffic. But since the switch knows where the device is located that wants to receive it, it relays traffic only to a specific port. Now in the MAC address table there is an entry with the MAC address of a multicast group that looks at a specific port.

  4. Periodically, the router sends to the IGMP network General Query . The switch sends it through all ports.

  5. After receiving IGMP General Query , the device responds with an IGMP Report . The switch intercepts it and sends it only in the direction of the router. Other multicast traffic recipients do not receive this message. And that means they respond with their own IGMP Report . Thus, the work of the Report Suppression mechanism is disrupted. This is necessary to identify all recipients of multicast traffic. Otherwise, the client, having heard the IGMP Report from another, decides that he does not need to answer, and the switch will not know about his presence. After receiving the IGMP Report from all, the switch updates its records. There is no sense to send all IGMP Report messages to the router, so only one thing is sent - the very first one.

  6. If the device decides to stop receiving traffic for a specific multicast group, it sends an IGMP Leave message. The switch intercepts it as usual.

  7. First, the switch will check if there are any other multicast traffic receivers behind the same port (where the IGMP Leave message came from). After all, another switch can be connected to this port. To do this, it sends an IGMP Group-Specific Query message. If there is no response, the switch simply removes the multicast group's MAC address to that port. If the answer came, continues to transmit traffic through this port.

  8. Next, the switch checks whether there are other recipients of multicast traffic for this group, but behind other ports. For this, he simply looks into his table of MAC addresses.

    • If there are such recipients, the switch does nothing more. Send a message IGMP Leave in the direction of the router does not make any sense.

    • If it was the last recipient for this multicast group, the switch sends an IGMP Leave message towards the router.


  9. Having received the IGMP Leave message, the router sends out IGMP Group-Specific Query messages, which the switch in turn sends through all its ports. Of course, no one responds and the router stops transmitting traffic for this group.

So, in general, we have dismantled the theoretical foundations. Let's try to see how it looks in practice. Our network topology will look like this:



The source and recipient of the multicast traffic will be implemented through the VLC media player (hereinafter referred to as the VLC player).

IGMP snooping is disabled, the source of multicast traffic is on another network

Let's start with the fact that we consider the transmission of multicast-traffic without using IGMP snooping technology. First, turn off IGMP snooping. As we remember, on Cisco equipment it is enabled by default:

cbs-sw-2960x#conf t cbs-sw-2960x(config)#no ip igmp snooping cbs-sw-2960x(config)#exit cbs-sw-2960x# cbs-sw-2960x#sh ip igmp snooping Global IGMP Snooping configuration: ------------------------------------------- IGMP snooping : Disabled

On the router, we enable multicast traffic routing and launch the protocol Independent Multicast multicast traffic routing protocol in dense-mode. We are not principled mode. The main thing is that the router launches IGMP on the interface we need and ensures the transfer of multicast traffic through itself.

At the source, turn on the VLC player in the streaming mode. This will be our source of multicast traffic. We will use 230.255.0.1 as the group address. We will transmit only audio over the network. As the transmitted composition choose Adele Rolling in the Deep. The moment is important, since it is the one that is best transmitted over the network (fact verified).

A little thorny path at the very beginning
I encountered the problem of routing multicast traffic when setting up the first computer, which was supposed to be the source. As an experimental, I took a few laptops used by the company's engineers.

I installed the VLC player, set up streaming audio transmission and ... did not see anything in the Wireshark dump on the external interface of this computer.

Looking into the routing table, I saw two routes to the network 224.0.0.0/4 with exactly the same metric 276. And the first on the list was a route through an interface with the address 169.254.55.11. And only the second was the route through the normal interface of this computer (172.17.16.11).



In this regard, all the multicast packets wrapped around an incomprehensible interface. Looking into the network connections, I discovered the activated Cisco Systems VPN Adapter interface. This interface appears in the system when the Cisco VPN client is installed on the computer. This is a rather old solution for connecting via VPN and, apparently, it was just forgotten to be deleted.



Disabling this interface solved the problem.

Next, on the client, turn on the VLC player in the streaming audio receiving mode for the group 230.255.0.1.

And again the problems ...
When I switched to setting up a streaming audio recipient, it didn’t work for me right away. Then I was not surprised at all, but immediately got into the routing table. On this computer, the symptoms were identical: multicast packets did not appear on the wired interface.


And again I found two routes to the network 224.0.0.0/4 with exactly the same metric 306. But now the first was the standard loopback route of the interface. Typically, the route metric for this interface is greater, metrics through other interests. For some reason in my case they were equal.

As it turned out, someone on this laptop in manual mode set the metric of the wired interface.


After I checked the “Automatically learn metrics” checkbox, multicast packets began to normally leave this computer.

As a result, on both computers there was a problem with multicast traffic routing, but in each case the source of the problem was different.

We immediately see how the multicast traffic went. In our case, these are streaming packets that use the UDP protocol at the transport layer.


Do not forget about TTL
It is worth noting that by default the VLC player sets the TTL for streaming packets to 1. This means that such packets cannot be transferred to another network, i.e. routed. Therefore, for our case in the VLC settings, the TTL value was set to more than one.

The dump shows that the recipient has requested traffic (sent a message from the IGMP Report) and the router immediately began broadcasting the necessary multicast traffic to the network. IGMP Report messages for two. Apparently, the second VLC player sends for fidelity. One message would be enough.

We check the routing table of multicast traffic on the router. Records appeared in it, indicating where and where traffic is transmitted:

 cbs-rtr-4000#sh ip mroute IP Multicast Routing Table Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet, X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement, U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel, z - MDT-data group sender, Y - Joined MDT-data group, y - Sending to MDT-data group, G - Received BGP C-Mroute, g - Sent BGP C-Mroute, N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, Q - Received BGP SA Route, q - Sent BGP SA Route, V - RD & Vector, v - Vector, p - PIM Joins on route, x - VxLAN group Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join Timers: Uptime/Expires Interface state: Interface, Next-Hop or VCD, State/Mode (*, 230.255.0.1), 00:29:20/stopped, RP 0.0.0.0, flags: DC Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/0/1.115, Forward/Dense, 00:29:20/stopped (172.17.16.11, 230.255.0.1), 00:03:27/00:02:32, flags: T Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0 Outgoing interface list: GigabitEthernet0/0/1.115, Forward/Dense, 00:03:27/stopped

We see that the source of multicast traffic is the host 172.17.16.11. In this case, the recipients are behind the interface GigabitEthernet0 / 0 / 1.115. The router remembers only where to send traffic. It does not keep the base of the recipients themselves (there is such a possibility in IGMPv3).

Let's look at the traffic dump on the client filtered by IGMP messages:


  1. Press the "Play" button in the VLC player and our computer requests to receive multicast traffic for the group 230.255.0.1, sending the message IGMP Report. As we have already noted, it sends two such messages.

    Having received this message, the router starts broadcasting multicast traffic (streaming audio) to the local network and on our client we begin to hear the music transmitted over the network.

  2. Periodically (every 60 seconds), the router sends an IGMP General Query message.

  3. Our computer responds to this message by sending back the IGMP Report for group 230.255.0.1.

  4. We make a “Stop” button in the VLC player and our computer sends an IGMP Leave message stating that it no longer wants to receive multicast traffic for the group 230.255.0.1.

  5. The router in response to IGMP Leave sends an IGMP Group-Specific Query message for 230.255.0.1. He wants to understand whether there are other recipients in this network segment. After exactly 1 second, the router sends a repeated message to the IGMP Group-Specific Query. And after another 1 second, without receiving a single IGMP Report in response, it stops transmitting multicast traffic to this network segment.

  6. Periodically, the router continues to send an IGMP General Query message. But since our computer is no longer interested in receiving anything, it does not respond to it.

Since IGMP snooping is turned off on the switch, all multicast traffic is sent (flooded) to all ports in our VLAN while there is at least one recipient. When there are no more recipients, the router will immediately stop sending traffic to this network segment.


Dump traffic from a computer in the same network segment, but not participating in receiving streaming traffic:


Likewise, all IGMP messages will be the case. They will be sent to all ports without exception. Which is absolutely logical, since all of these messages use the multicast address as the recipient's address.

IGMP snooping is enabled, the source of multicast traffic is on another network

We now turn to the consideration of the situation when IGMP snooping is enabled on the switch. Launch IGMP snooping on Cisco 2960x:

 cbs-sw-2960x(config)#ip igmp snooping cbs-sw-2960x(config)#exit cbs-sw-2960x# cbs-sw-2960x#sh ip igmp snooping Global IGMP Snooping configuration: ------------------------------------------- IGMP snooping : Enabled

First, we check to see if the switch could detect the router. As we remember, this is the first item on the IGMP snooping task list:

 cbs-sw-2960x#sh ip igmp snooping mrouter Vlan ports ---- ----- 115 Gi1/0/19(dynamic)

We see that behind the port Gi1 / 0/19 our router hid. As we discussed earlier, the switch looks at the presence of packets in the network, indicating the presence of a router. In the case of the 2960x, the switch waits for IGMP General Query, PIM or DVMRP packets.

 Sep 17:39:39 MSK: IGMPSN: router: PIMV2 Hello packet received in 115 Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19 Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19 Sep 17:39:39 MSK: IGMPQR: vlan_id 115: querier/multicast router detected on port Gi1/0/19 in Disabled state Sep 17:39:39 MSK: IGMPSN: router: Created router port on Vlan 115, port Gi1/0/19 Sep 17:39:39 MSK: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 115. Sep 17:39:39 MSK: IGMPSN: Adding router port Gi1/0/19 to all GCEs in Vlan 115 Sep 17:39:39 MSK: IGMPSN: added rport Gi1/0/19 on Vlan 115 Sep 17:39:39 MSK: IGMPSN: router: Learning port: Gi1/0/19 as rport on Vlan 115

The switch saw the PIMV2 Hello message from the router on port Gi1 / 0/19 and added information about it to itself.

Run our streaming audio stream again and see what we have on the router:

 (*, 230.255.0.1), 00:00:12/stopped, RP 0.0.0.0, flags: DP Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Null (172.17.16.11, 230.255.0.1), 00:00:12/00:02:47, flags: PT Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0 Outgoing interface list: Null

— 172.17.16.11. , : Outgoing interface list: Null.

VLC, «» . Wireshark, , multicast- :


Now the fun part. IGMP - -.

:

1. «» VLC, multicast- 230.255.0.1, IGMP Report.


Note

, IGMP Report, , , ( – GE0/0/15) MAC- 01:00:5e:7f:00:01.

Remark MAC- . , «show mac address-table».

2. IGMP Report . , , . , :


Note . MAC

, 230.255.0.1, (GE0/0/15) . , , . , .

3. .


Note

4. GE0/0/15, .


Note

5. multicast- ( IGMP VLC ).


Note

, . .

6. IGMP General Query.

7. .


Note . MAC

8. , IGMP Report 230.255.0.1.

9. IGMP Report ( ) .


Note . MAC

, IGMP Report . , IGMP snooping. Those. Report Suppression . IGMP Report IGMP General Query. , multicast- .

10. «» VLC. IGMP Leave, , multicast- 230.255.0.1.


Note

11. IGMP Group-Specific Query 230.255.0.1. , , :


Note . MAC . IP- 172.17.15.1 ( )

Those. , IGMP Leave, , , multicast- 230.255.0.1.

. , , - multicast-.

12. IGMP Group-Specific Query.

13. , IGMP Report, multicast- .


Note . 13:32:58:58

14. , , , IGMP Leave, , , . MAC- MAC- 01:00:5e:7f:00:01 ( , MAC- 230.255.0.1). , multicast-. , . IGMP Leave.


Note . MAC

15. IGMP Leave, , . , . IGMP Group-Specific Query 230.255.0.1.

16. . , . :


Note . MAC

17. IGMP Group-Specific Query.

18. , IGMP Report ( , , ), .


Note . 13:33:00:65

19. IGMP General Query.

20. .

, , , . UDP .

(-):



(-):




, . IGMP . . . IGMP . multicast-, . , – . , , IGMP snooping. Those. IGMP snooping.

, , .


Note MAC

, multicast- :

  1. IGMP Group-Specific Query, , multicast-.
  2. IGMP General Query, .

, IGMP snooping , -, multicast- , . Those. .


-, IGMP . multicast-. , .

-, IGMP , , multicast-. , IGMP snooping IGMP .

, :

 cbs-sw-2960x#sh ip igmp snooping groups Vlan Group Type Version Port List ----------------------------------------------------------------------- 115 230.255.0.1 igmp v2 Gi1/0/14, Gi1/0/15, Gi1/0/19

, multicast- 230.255.0.1 Gi1/0/14, Gi1/0/15 Gi1/0/19. Gi1/0/19 . . debug ip igmp snooping.

IGMP snooping , multicast-

, - , . multicast- , . . , STB-. VLC , , - , , . – multicast- . IGMP snooping?

PIM, multicast-.

IGMP snooping : . , IGMP snooping , . VLC (.. IGMP ).

, , , multicast-:


, IGMP snooping . , , VLC 230.255.0.1 ( ). «», , IGMP Report, . , multicast- . VLC :


IGMPv3
, , IGMPv3. IGMPv2. , Cisco IGMPv2. Windows (7, 8, 10) IGMPv3. IGMP , IGMPv2 General Query, . IGMP, .

, multicast- . IGMP snooping , . But no. Nothing has changed. , , multicast- ( , multicast- ). , IGMP Report, , , , . IGMP snooping - : IGMP .


. :

 cbs-sw-2960x#sh ip igmp snooping groups cbs-sw-2960x#

(debug), :

 Sep 13:54:01 MSK: IGMPSN: Received IGMPv3 Report for group v3 received on Vlan 115, port Gi1/0/15 Sep 13:54:01 MSK: IGMPSN: Rx IGMPv3 Report on Gi1/0/15 when Querier is not IGMPv3, Vlan 115.

, , — IGMPv3 Report, Querier IGMPv3 ( Querier ). , IGMPv3 IGMPv2 ( ). .

We are checking. , :

 Sep 15:07:08 MSK: IGMPSN: Received IGMPv2 Report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15 Sep 15:07:08 MSK: IGMPSN: group: Received IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15 Sep 15:07:08 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/15 Sep 15:07:08 MSK: IGMPSN: group: Skip client info adding - ip 172.17.15.11, port_id Gi1/0/17, on vlan 115 Sep 15:07:08 MSK: IGMPSN: No mroute detected: Drop IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15

, IGMP ( ), «mroute». , IGMP snooping , . multicast- . «show ip igmp snooping mrouter». , , IGMP General Query. , IGMP snooping , multicast- . , , mrouter- (multicast router port). mrouter- IGMP snooping . , IGMP.

IGMP ( PIM). , mrouter-:

 cbs-sw-2960x#sh ip igmp snooping mrouter Vlan ports ---- ----- 115 Gi1/0/19(dynamic)

. VLC . , . Not. , multicast- – mrouter-. , IGMP Report , multicast- . , multicast-.

Comment. , multicast- , multicast , . multicast- IGMP Report 230.255.0.1.

VLC , multicast- . -- IGMP , , . .

, ( UDP- ):


, :




, , IGMP snooping Cisco . mrouter- IGMP ? , ? , . – mrouter-. , . , . , . – IGMP Querier. multicast- IGMP. mrouter- :

 cbs-sw-2960x#sh ip igmp snooping mrouter Vlan ports ---- ----- 115 Switch

IGMP General Query. This is a big plus. , , , – multicast-, mrouter-. , IGMP snooping .

Comment. multicast- mrouter-. , , mrouter-. , , IGMP Querier.

. Cisco IGMP snooping, , mrouter-. mrouter-:

  1. IGMP snooping ( , , ) multicast-, , . .

  2. IGMP Report.

mrouter- IGMP snooping, multicast- mroute-. .

IGMP snooping 224.0.0.X

IGMP snooping, , multicast-, 224.0.0.0-255 (224.0.0.0/24).

, ( ). IP- . , 224.0.0.5 OSPF, 224.0.0.10 – EIGRP. / . Those. IGMP Report. IGMP snooping Cisco .

IGMP Report. , 224.0.0.251 224.0.0.252. Multicast DNS Link-Local Multicast Name Resolution, .
 Sep 17:27:36 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15 Sep 17:27:36 MSK: IGMPSN: 224.0.0.251 is a Reserved MCAST address Sep 17:27:36 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15 with invalid group address Sep 17:27:37 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15 Sep 17:27:37 MSK: IGMPSN: 224.0.0.252 is a Reserved MCAST address Sep 17:27:37 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15 with invalid group address

Cisco , , «224.0.0.». IGMP Report.

Finally


IGMP snooping Cisco. « ». , (, IGMP Group-Specific Query), IGMP Leave (, , ), STP (, , ) . .

, IGMP snooping. , , - (, mrouter- router-), , . IGMP snooping , .

Source: https://habr.com/ru/post/309486/

More articles:


All Articles