Multicast IP Address to MAC address mapping

maybe im missing the obvious - but if for the mac address the first part is always 01-00-5E

then the last 23 bits get the Multicast IP address
is the 24th bit in the MAC address always assumed to be 0 then because its a don’t care ?

Hi Jeffrey,

AFAIK the 24th bit doesn’t have any special meaning, it’s just that IANA has assigned 01-00-5E as the OUI for Multicast MAC.

Rene

thanks - I meant the 24th bit from the right in the MAC.
the first 23 are from the IP address.
the 24th bit is an “x”
and the rest is always 01-00-5E

is the 24th bit always 0 ?
it must be

Hi Jeffrey,

It doesn’t have to be, the RFC has the answer:

http://www.iana.org/assignments/ethernet-numbers/ethernet-numbers.xhtml

Look for the “IANA Multicast 48-bit MAC Addresses” part. The range for IPv4 unicast is 00-00-00 to 7F-FF-FF so then the 24th bit will always be a 0. Some of the other ranges (MPLS multicast for example) will use a 1 for the 24th bit.

Rene

Awesome- thanks

Rene - if there is one source 224.1.0.1 and two receivers.
one receiver is listening for 239.1.0.1 and one listening to 226.1.0.1
all three of those MAC addresses will over lap right ?

if the receivers are on different LAN segments in the network will they both get the packets ?

Hi Jeffrey,

The source will always be a unicast address, the destination can be a group address. There will be some duplicate packets yes…routers might receive duplicate packets but forwarding will be OK since they route multicast packets based on L3 information in the multicast routing table. Receivers will receive duplicate packets if they are on the same Ethernet segment, the switch is only looking at destination MAC addresses so the receivers will receive packets from both groups.

Rene

ok thank you for explaining

FYI: There was an error in translating from Hex to Binary. You correctly state that 5 in binary is 0101 in your reference table, but when it comes time to translate the “5” in your 01:00:5e:0b:01:02, the binary is transposed to 1001 (9) instead of 0101 (5). You got lucky in that the 5 was higher than the significant 23 bits of the example, so it wound up having no effect on the results.

Hi Andrew,

Thanks for reporting this, you have a good eye :slight_smile: Just fixed the error.

Rene

Hi Rene,

Excellent creation as usual . Please confirm my understanding is correct which is grabbed from this lesson. Please let me know if I am wrong :slight_smile:

General format of MAC address is MM:MM:MM:SS:SS:SS.The leftmost 6 digits (24 bits : MM:MM:MM ) called a “prefix” is associated with the adapter manufacturer.
The rightmost digits (24 bits : SS:SS:SS) of a MAC address represent an identification number for the specific device with the same vendor prefix.

But here in this multicast we use the leftmost 3 octets are (24 bits : MM:MM:MM) always 01-00-5E and the right most digits(24 bits : SS:SS:SS) will be a single OUI (24bits). From this single OUI(24 bits) we use only half of this 24-bits which means 23 bits can be used for mapping 28 bits Mutlicast IP addresses.

Hello Sreenath,

That sounds correct yes, seems you got it :slight_smile:

Rene

I have a router on a stick lab. 1 2960 divided into 2 vlans connected to router subinterface. Is there any commands that need o be configured on a switch for multicast traffic?

Hi Jason,

Do you want to use multicast within the VLAN or route multicast traffic between VLANs?

There’s not much you have to do on the switch, you might want to read up on IGMP snooping to see how it works:

IGMP snooping is enabled on most switches by default.

Rene

In terms of Layer 2 multicast addresses, it seems there are some exceptions to the 0100.5e.X prefix rule?

0100.0ccc.cccd is for PVST and is considered multicast
0180.c200.0000 is for regular spanning tree and considered multicast

I suppose these will never map to Layer 3 addresses so that’s probably why they appear random.

Hello Chris

You are correct that these layer two addresses are indeed multicast addresses. However, these function for exclusively layer two protocols such as PVST, STP, CDP, VTP, UDLD and others. This means that there is no corresponding multicast IP address to map them to. Multicast IP addresses are only mapped using the stated rule.

I hope this has been helpful!

Laz

That exactly is my doubt

Since some Multicast IPv4 addressses map to the same multicast mac add :slight_smile:
if we have to host H1 & H2, H1 joins to 239.1.139.1 and H2 joins to 224.1.139.1, both are on the same segment, but H1 also will receive multicast packets for the other group (224.1.139.1) and also H2 will receive L2 multicast traffic for the other group (239.1.139.1) … that’s right ?

But H1 Nic interface will drop this l2 multicast traffic ? unlike broadcast traffic that will be passed through the nic to the cpu ?

Hello Juan

Yes that is correct. But in order to have duplicate packets a lot of unlikely things have to happen simultaneously, so it is a rare occurrence. If the network administrator is on top of things, he or she will make sure to use appropriate group addresses to avoid such a situation.

Yes, the NIC will indeed drop this multicast traffic. Remember that the NIC is “multicast aware” so it knows to which multicast groups it belongs. If it receives multicast traffic with a destination multicast IP address different from those groups to which it belongs, it will drop the packet.

I hope this has been helpful!

Laz

Ask me a question please. Throughout the text we say that the MAC address has 48 bits and that the first 24 bits are fixed for multicast addresses.
There are 24 bits left. My question is why is it said that half of these remaining 24 bits are 23 bits?
I confess that I am confused by the explanation.

Hello Marcelo

Yes this is indeed confusing. Remember that we’re talking about binary. If you have 24 bits available, you can represent 2^24 numbers, which is numbers between 0 and 16,777,216. If you take away the leftmost bit from these 24 bits, you’re left with 23 bits. This means you can represent 2^23 numbers, or numbers between 0 and 8,388,608.

8,388,608 is half of 16,777,216.

Every time you reduce the number of bits representing a binary number, you divide it by two which is the base of the binary system. The same happens with decimal, but in decimal, you divide by 10 because 10 is the base of the decimal system. For example, if you have the number 9999, and you remove one digit, you get 999 which is 10 times smaller.

I hope this has been helpful!

Laz