Wired Intelligent Edge (Campus Switching and Routing)

Multicast Clients Not Getting Video Stream Because Of Well-Known Multicast IP Addresses

MVP Expert
MVP Expert
Problem:

Multicast clients were not getting the video stream. The issue was only seen in the Aruba switch that acted as layer 3 device.



Diagnostics:

Below was the network diagram:

 

The Multicast source was connected to the Comware device and the client in question was connected to the HPE switch. Both the source and the client were in different vlans. PIM-sparse was enabled in all of the switches with the comware switch as the RP.

The client connected to the comware devices worked fine but the client connected to the HPE switch did not receive any multicast packets. By checking the packet capture in the client we could verify that the client was sending the IGMP report, inorder to get the stream. But the HPE switch being the querier did not have any entries in its IGMP table for the multicast group the client was requesting to join.

Debugging IGMP in HPE switch showed that the switch received the reports from the client but did not add it to the IGMP table, because of which the query did not reach the RP at all.



Solution

Each multicast host group is identified by a single IP address in the range of 224.0.0.0 through 239.255.255.255. Here 239.0.0.1 was in use.

Specific groups of consecutive addresses in this range are termed "well-known" addresses and are reserved for predefined host groups. IGMP does not filter these addresses, so any packets the switch receives for such addresses are flooded out all ports assigned to the VLAN on which they were received (except the port on which the packets entered the VLAN.)

Table 4 IP multicast address groups excluded from IGMP filtering
 
Groups of consecutive addresses in the range of              Groups of consecutive addresses in the range of
224.0.0.X to 239.0.0.X                                                                     224.128.0.X to 239.128.0.X
224.0.0.x              232.0.0.x                                                              224.128.0.x         232.128.0.x
225.0.0.x              233.0.0.x                                                              225.128.0.x         233.128.0.x
226.0.0.x              234.0.0.x                                                              226.128.0.x         234.128.0.x
227.0.0.x              235.0.0.x                                                              227.128.0.x         235.128.0.x
228.0.0.x              236.0.0.x                                                              228.128.0.x         236.128.0.x
229.0.0.x              237.0.0.x                                                              229.128.0.x         237.128.0.x
230.0.0.x              238.0.0.x                                                              230.128.0.x         238.128.0.x
231.0.0.x              239.0.0.x                                                              231.128.0.x         239.128.0.x

 

The same multicast IP worked fine in the comware device. Changing the IP to one that does not fall into the well-known range fixed the issue. 

The reason that our igmp implementation does not add the group address 239.0.0.0/24 to the IGMP forwarding table is because it maps to the multicast MAC address “ 0x0100-5E00-00xx”  - this address is always flooded which defeats the purpose of using IGMP.

Version history
Revision #:
1 of 1
Last update:
‎06-26-2019 12:07 AM
Updated by:
 
Search Airheads
cancel
Showing results for 
Search instead for 
Did you mean: