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 
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
Has the issue of having multiple IP address correlate to the same mac address been resolved or this is something a network engineer need to take into account when designing network/ip address?
Hello Abdulrahman
The āissueā of having multiple IP addresses mapped to the same MAC address is not something that has been solved, as you put it, but something that exists and should be taken into account by network engineers. By using only specific multicast addresses, engineers can steer clear of addresses that may map to the same MAC address.
Even if an engineer is unaware, it is unlikely that you will have multiple multicast IP addresses mapping to a single MAC address. Not impossible, but unlikely. If this does take place, multicast will still function correctly. As a multicast client decapsulates its received multicast packet, it will see the destination IP address, and will simply discard it if it does not belong to this multicast group. It adds a little overhead, but it doesnāt break the multicast operation.
I hope this has been helpful!
Laz
1 Like
Good explanation on how to get through the teeth numbing number crunching. But I think important statement is missing - why do we need it? I.e. why do we need to construct mac address from IP address? And who and how does it - client, routers, switches or all of them?
Hello Vadim
These are excellent questions that help to understand the reasoning behind these mechanisms.
In unicast communication, a host is assigned an IP address, and it also has its own hard-wired MAC address. So when communication on a network takes place, the encapsulation process knows what IPs to put in the destination IP address field of the IP header, and what MAC addresses to put in the destination MAC address field of the Ethernet header. This is because there is a one-to-one ratio of IP addresses to hosts, and MAC addresses to hosts.
When using multicast, a single multicast IP address, such as 231.1.1.1 for example, corresponds to a group of hosts. When a device prepares to send an IP packet to 231.1.1.1, it must encapsulate it into an Ethernet frame. Ethernet frames require a source and destination MAC address. The source is easy since it is the MAC address of the sending device, but what MAC address should be placed in the destination field? We use the method described in the lesson to determine what MAC address to place in the destination MAC address field.
The algorithm to determine the multicast MAC address to use is the same and is generated by both multicast sources as well as multicast hosts. When a multicast source prepares to encapsulate a multicast IP packet, it calculates the corresponding MAC address and places it in the destination MAC address field. Multicast hosts on their end also calculate their multicast MAC addresses so that if a multicast packet arrives, as they decapsulate it, they will read the destination MAC, and determine (from the multicast IP address groups they belong to) if the frame is indeed intended for them.
As for switches, they will simply use the normal method of building the MAC address table, where MAC addresses (whether unicast or multicast) will correspond to particular ports.
Multicast router interfaces will also adopt the multicast MAC addresses that correspond to the groups that they forward traffic to so that any multicast packet sent on a particular subnet that needs routing, will be received by the local router and processed.
I hope this has been helpful!
Laz
Ok, thank you. So in case of broadcast we obviously donāt need to construct anything as it is just a fixed mac. Only multicast requires additional processing to build mapping between IP and MAC. And I guess ARP is not needed in case of multicast, either, since sender is supposed to construct destination MAC on its own instead of asking who has MAC for destination IP as in the case of unicast. Several different group IPs could be mapped to the same MAC but it just cant be avoided without complete rebuilding the whole concept of the multicast and at least any particular group IP can be mapped to only single particular MAC. So all works even if at times the hosts might do additional processing filtering out undesired IPs who are sent to the MAC they have on their interface.
Hello Vadim
Yes, that is correct. In the event of a broadcast, the MAC address is always FF:FF:FF:FF:FF:FF, so no processing is needed to determine this. Multicast does indeed require additional processing to build that mapping.
Yes that is correct, ARP is not necessary here.
Exactly. In the event that an incorrect frame is accepted because of the lack of this MAC address uniqueness, then it will be further decapsulated to the Network layer where the destination (multicast) IP address will be examined. If the host does not belong to this multicast group, then the packet will be dropped. The chances of that happening are very small, and if it does happen, the burden on the CPU is negligible.
I hope this has been helpful!
Laz
In the Mac address, now first 3 octets are reserved(01-00-5E) for multicast usage, Can we reduce this size to 2 octets or less (eg: 5E-5E). so that we can map each ip to unique Mac in 1:1 ratio. and can improve the bandwidth and security by eliminating the unwanted packets to hit the host.
Thanks
Ashish
Hello Ashish
Although it is theoretically possible to do this, so that you will indeed have a 1:1 correspondence between the multicast MAC and IP ranges, this is not a viable solution. This is because MAC addresses have been designed to have two distinct sections, the OUI which defines the vendor, which is 24 bits, and the second section which defines the unique device identifier. This arrangement cannot be adjusted, so only 24 bits are made available to the multicast MAC address range.
Now having said that, the mechanism of mapping multicast MACs to IPs is such that the possibility of duplication is very small. Even if it happens, the switch will simply drop any incorrect matches that take place without any substantial bandwidth or resource usage. The arrangement works very well and does not really affect performance in any way.
I hope this has been helpful!
Laz
Hello,
Regarding these multicast addresses:
224.1.1.1
224.129.1.1
225.1.1.1
ā¦
ā¦
ā¦
238.1.1.1
238.129.1.1
239.1.1.1
we basically canāt us them as destination group addresses right? 225.1.1.1, 225.1.129.1, 226.1.1.1, 226.1.129.1 etc etc right?
Thank you
Hello Fabian
Actually, you can use them, and they will work fine. The only issue you will have, as stated in the less, is that a host may receive and accept a frame that belongs to a different multicast group. If this happens, the host will have to decapsulate the frame and examine the destination IP address in the IP header. If it is not to a destination multicast address to which the host has joined, it will simply be discarded.
So rather than discarding the frame, it will actually be processed up to the 3rd layer and discarded then. So it is adding more processing to the host. This will only be a problem under extremely high multicast traffic. Otherwise in most situations you probably wonāt notice a difference.
Now having said that, best practice dictates that you should not uses these addresses simultaneously in your network to avoid any unnecessary processing by the hosts.
I hope this has been helpful!
Laz
Hello, everyone
Each OUI costed $1000, and Steveās manager didnāt want to pay 16 x $1000 = $16.000 just for MAC address space. As a result, Steveās manager bought a single OUI (24 bit) and gave half of the space (23 bit) to Steve to use for his multicast research. Why does this matter? Let me show you:
I donāt understand this explanation. If you have a 48-bit MAC and the OUI is 24 bits, the remaining half should also be 24 bits, right? Since half of 48 is 24. So why does the article say 23?
I was also a little confused by this part
We miss 5 bits of mapping information: 25 = 32. This means we will map 32 multicast IP addresses to 1 multicast MAC address. Hereās an example:
What this means is that each multicast MAC will represent 32 different IPs, correct? To account for the fact that we lack 5 bits. Since 2 to the power of 28 is 268435456 possible multicast addresses and that value divided by 32
Is the amount of MACs that can be constructed from those 23 bits
So 1 Multicast MAC = 32 multicast IP addresses, right?
Thank you.
David
Hello David
What the text is saying, is that Steveās manager bought a single OUI, which means that all of the MAC addresses that are made available to Steve start with the same 24 bits. For example, letās say that the OUI that Steveās manager purchased was, in hex, AB:CD:EF. Thatās 24 bits right?
Now the rest of the MAC address space available is comprised of the next 24 bits. So we have a range from AB:CD:EF:00:00:00 to AB:CD:EF:FF:FF:FF. Now of that address space of 24 bits, we want to give half of that to Steve for his multicast research. If we take a look at our last 24 bits in binary, we have a range from:
00000000 00000000 00000000
to
11111111 11111111 11111111
Now, we want to give only half of that address space to Steve. To do so, we simply give him 23 of the 24 bits. So he can play with values from
00000000 00000000 00000000
to
01111111 11111111 11111111
To prove that this is half of the address space, take a look at this:
11111111 11111111 11111111 = 16777215
01111111 11111111 11111111 = 8388607
16777215/8388607 = 2
Yes, thatās absolutely correct. You see, the IP multicast address space is 32 times the size of our MAC multicast address space. That means that when we map our multicast IP addresses to our multicast MAC addresses we have a 32:1 ratio.
For more info about this mapping, take a look at this NetworkLessons note.
I hope this has been helpful!
Laz
1 Like