When I did multicast testing on my wireless network last couple of days I noticed few things may worth to note here.
First thing is the group addresses used by different services which we may not aware of. During my “VideoStream” testing I have used 188.8.131.52 group address for my video stream. But when I monitor multicast on my controller I have noticed lot of other multicast group addresses listed there(see below).
When I search these group addresses on web, I found that certain private multicast (239.x.x.x) group addresses used for specific applications. (Ref:http://www.multicast.org.uk/address-tools/scope-relative.html). Since I have used SAP for my multicast stream session announcement, these group addresses shown in my wireless network. Usually these are top end of addresses in a given class B & better to avoid it using for your application group addresses.
Local Scope Relative
184.108.40.206 – SAP (Session Announcement Protocol)
220.127.116.11 – MADCAP Protocol
18.104.22.168 – SLPv2 Discovery
22.214.171.124 – MZAP
126.96.36.199 – Multicast Discovery of DNS Services
188.8.131.52 – SSDP
184.108.40.206 – DHCPv4
220.127.116.11 – AAP
18.104.22.168 – MBUS
Organization Scope Relative
22.214.171.124 – SAP (Session Announcement Protocol)
126.96.36.199 – MADCAP Protocol
188.8.131.52 – SLPv2 Discovery
184.108.40.206 – MZAP
220.127.116.11 – Multicast Discovery of DNS Services
18.104.22.168 – SSDP
22.214.171.124 – DHCPv4
126.96.36.199 – AAP
188.8.131.52 – MBUS
Multicast Address range 184.108.40.206/24 is allocated for “Local Network Control” 220.127.116.11/24 ” is for “Internetwork Control” by IANA. (Ref http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml#multicast-addresses-1) These local network multicast packet go with TTL=1 & therefore cannot go beyond local subnet. I think Apple is using certain of these group address discover certain services within local subnet. In my environment I had iPad3 with AppleTV. They use mDNS (18.104.22.168) group address for that. 22.214.171.124 is using for SAPv1 announcement.
The second thing need to note is how multicast destination MAC address derived from a multicast IP address.IP multicast addresses have been assigned to Class “D” address space by the Internet Assigned Number Authority (IANA). Addresses in this space are denoted with a binary “1110” prefix in the first four bits of the first octet, as shown in below figure. This results in IP multicast addresses spanning a range from 126.96.36.199 through 188.8.131.52.
The IEEE 802.2 specification makes provisions for the transmission of broadcast and multicast packets. As shown in below figure, Bit 0 of Octet 0 in an IEEE MAC address indicates whether the destination address is a broadcast/multicast address or a unicast address. If this bit is set, the MAC frame is destined either for an arbitrary group of hosts or all hosts on the network (if the MAC destination address is the broadcast address 0xFFFF.FFFF.FFFF). IP multicasting at Layer 2 uses this capability to transmit IP multicast packets to a group of hosts on a LAN segment.
All IP multicast frames all MAC layer addresses beginning with the 24-bit prefix of 0x0100.5Exx.xxxx. With only half of these MAC addresses available for use by IP Multicast, 23 bits of MAC address space is available for mapping Layer 3 IP multicast addresses into Layer 2 MAC addresses. All Layer 3 IP multicast addresses have the first four of the 32 bits set to 0x1110, leaving 28 bits of meaningful IP multicast address information. These 28 bits must map into only 23 bits of the available MAC address. This mapping is shown graphically in below figure.
Because all 28 bits of the Layer 3 IP multicast address information cannot be mapped into the available 23 bits of MAC address space, five bits of address information are lost in the mapping process. This results in a 32:1 address ambiguity when a Layer 3 IP multicast address is mapped to a Layer 2 IEEE MAC address. This means that each IEEE IP multicast MAC address can represent 32 IP multicast addresses as shown in below figure.
This 32:1 address ambiguity has the potential to cause problems. For example, a host that wishes to receive multicast group 184.108.40.206 will program the hardware registers in the network interface card to interrupt the CPU when a frame with a destination multicast MAC address of 0x0100.5E00.0101 is received. Unfortunately, this same multicast MAC address is also used for 31 other IP multicast groups. If any of these 31 other groups are also active on the local LAN, the host CPU will receive interrupts when a frame is received for any of these other groups. The CPU must examine the IP portion of each of these received frames to determine if it is the desired group; for instance, 220.127.116.11. This can affect the host’s available CPU power if the amount of “spurious” group traffic is high enough.(Ref:http://www.cisco.com/en/US/tech/tk828/technologies_white_paper09186a00802d4643.shtml)
Due to this reason if you want to use private multicast for your application avoid using 239.y.x.x & 239.(y+128).x.x together for your applications as these will map into same Multicast MAC address. Specially 239.0.0.X & 239.128.0.x range as it overlap with link local addresses & flood out to all switch ports even with IGMP snooping turned on.
In my wireless packet capture shown below (taken for a previous post) shows 18.104.22.168 mapping to layer 2 MAC 01:00:5e:7f:ff:c8. To understand how this came, you can convert last 23 bits of this layer 3 addresss (11101111-11111111-11111111-11001000) into hex (7f:ff:c8). Therefore multicast MAC address should be 01:00:5e:7f:ff:c8. You can verify if from the capture itself.
Sometimes it is important to understand these sorts of things when you allocate multicast group addresses for your applications to prevent unexpected behavior.