cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
8337
Views
15
Helpful
6
Comments
Peter Paluch
Cisco Employee
Cisco Employee

A good friend of mine brought up an interesting question: We know that when a multicast IPv4 packet is encapsulated into an Ethernet frame, the destination MAC address is constructed using the OUI prefix of 01:00:5E and the lowmost 23 bits of the destination IPv4 address are directly copied to the lowmost 23 bits of the destination MAC address (the topmost bit in the 4th MAC octet is set to 0). Now, what will switches and routers as transit devices do if they receive a multicast frame but the destination MAC does not correspond to (is not constructed from) the destination IPv4 address of the packet in the frame? Will they observe the MAC address, or the IP address, or will they do something unexpected?

Surely enough, that was an interesting - and not an easy - question to answer, even though such situation should not occur with well-behaved networking software implementations.

Analyzing the options

After a brief deliberation, it was clear that a simple Layer2-only Ethernet switch would not care about the discrepancy between the destination IP and MAC addresses. To a basic Layer2 switch, any destination MAC address with its I/G bit set to 1 (a group destination address) is essentially unknown and unlearnable because no host would use such an address as its source MAC. As a result, any simple Layer2 switch will flood all multicast frames indiscriminately, and it will not care about any discrepancy between the destination MAC and the destination IP address of the packet inside the frame - after all, a basic Layer2 switch has no idea about IP whatsoever.

It was also fairly clear that routers should not care much, either. With respect to the operation of a router, the destination MAC address is important only to the degree of the router's incoming network interface card (NIC) treating that address as one of addresses it is listening to, because that is what makes the NIC to receive the frame and pass its contents to the corresponding driver for further processing. After that is done, however, the router no longer cares for the particular destination MAC address. In particular, if a router's interface is enabled for multicast routing then its must be prepared to receive frames destined to an entire range of group MAC addresses. Depending on the capabilities of the particular NIC controller, there are multiple ways of doing that:

  • The interface can be put into promiscuous mode in which it processes all received frames unconditionally. As an example, this approach is used with Cisco routers using Gt96k FastEthernet controller (2691, 1841 to name a few). Because this behavior could potentially lead to ill behavior such as looping of unicast packets for no apparent reason (this was a bug in Dynamips v0.2.11 and older - read this discussion where I submited a correction to Dynamips and explained the rationale), IOS will maintain an additional software-based MAC address filter to filter out frames that were received by the NIC but are not really intended to be processed by this router.
  • If the interface controller supports a special mode for receiving all multicasts, it can be used in place of promiscuous mode, as it will prevent issues with unintended receiving and processing of unicast frames. The software-based MAC address filter may still be necessary to filter out unwanted multicast MAC addresses.
  • The interface controller may support multiple MAC addresses and masks or MAC address hash tables to cover entire ranges of MAC address space. This approach is used, for example, with Cisco 3620 routers that use the AMD Am79C971 controller.

Regardless of the method, once the frame is received and accepted by the NIC, the router should process the packet in the frame.

The only case I was not at all certain was with a switch running IGMP Snooping. The purpose of IGMP Snooping is to allow the switch to learn about attached multicast receivers and the multicast groups they have subscribed into, so that in the ideal case, multicast flows are forwarded out only to the intended receivers and not flooded anymore. However, this is much easier said than done. How does the IGMP Snooping really work? Does it add and remove multicast MAC entries to the CAM table, or does it perform its filtering based on actual IP headers and destination addresses? Obviously, it could be done either way, so the only answer was to do a lab experiment.

So the hypotheses to verify or refute were:

  • A router does not care about the discrepancy between the destination IP and MAC. Once its NIC accepts the frame, the packet will be forwarded according the multicast routing rules based on the destination IP address.
  • A naive Layer2 switch only cares about the destination MAC address and will always flood the frame out all remaining ports in the ingress VLAN.
  • A switch with IGMP Snooping enabled will do something special - and it is up to the experiment to show what exactly will happen.

Lab setup, experiments and results

To test the behavior of routers and switches receiving multicast traffic with incongruent MAC and IP, it was necessary to write a software to generate such traffic. I have therefore first written a simple hackish tool for Linux in C language that opens a packet (AF_PACKET) socket and creates an entire Ethernet frame + IP packet from scratch. This allowed me to arbitrarily fill in the individual frame and packet header fields and bypass the IP driver in the operating system.

Testing the router

Testing the hypothesis with a router was simple. I have used a 1841 series router in a simple topology:

Sender ---> fa0/1 - Router - fa0/0 ---> Receiver

The router was configured with PIM-SM, acting as its own RP. The receiver joined the multicast group 239.1.2.3 by starting VLC and having it subscribe for this group. The sender was configured to send a multicast stream to 239.1.2.3 with different destination MAC addresses: 0100.5e01.0203 (the correct one), 0100.5e71.7273, ffff.ffff.ffff, and even unicast MAC address of router's fa0/1. In each one of these cases, the multicast stream successfully made it to the receiver, and the receiver always received it with the proper destination MAC address which was expected, as the router performed its own encapsulation when it forwarded the packet further. Sending the IPv4 multicast traffic to the IPv6 MAC address range 3333:xxxx:xxxx caused the traffic to be dropped, though, because the router did not add the 3333:xxxx:xxxx MAC range to its software MAC address filter as it was not configured for IPv6 multicast routing.

This confirms the hypothesis that as long as the router's NIC accepts the frame, the multicast traffic will be routed and forwarded correctly, regardless of the destination MAC address.

Testing a simple switch

To test a simple switch, I have done testing on Catalyst 2950, 2960, and 3560 series with the IGMP Snooping explicitly deactivated. The topology was very simple - one sender and two receivers attached to this switch. A multicast-enabled router was also connected to the switch to act as an IGMP Querier (2950 does not support its own IGMP Querier).

As was expected, these switches with deactivated IGMP Snooping did not care about the MAC/IP correspondence in the received traffic, and happily flooded all received multicast to all remaining ports within the ingress VLAN.

Testing a switch with IGMP Snooping

These tests were by far the most interesting, and - as I slightly expected - the results differed based on the switch platform. I have reused the physical topology from the previous testing. In the further text, the saying "receiver received a stream" is used to mean that the Wireshark running on the receiver did display the stream being delivered to the receiver.


On a Catalyst 2950 switch, IGMP Snooping appears to populate the MAC CAM table with multicast addresses derived from received IGMP Membership Reports. After that, the 2950 strictly observes the incoming frame's destination MAC addres and forwards it based exclusively on the MAC address. The destination IP address of the packet in the frame is irrelevant. As an example, I have streamed my traffic to 239.1.2.3 but the MAC address was set to 0100.5e71.7273 which would correspond to any address of the set <224-239>.{113,241}.114.115. Now, a receiver subscribed to 239.1.2.3 was not receiving this stream at all. On the other hand, a receiver subscribed to 239.113.114.115 did receive this stream because by MAC address, it appeared to be what the receiver wanted.

As an additional test, I have tried streaming the same IP traffic in frames with destination MAC address of 0100.5e00.00e0 which would correspond to the link-local multicast 224.0.0.224 (as well as all 32 groups of the <224-239>.{0,128}.0.224 set). Unsurprisingly, this stream was flooded by the 2950 to every connected host.

Catalyst 2950 with IGMP Snooping creates multicast MAC address entries in the CAM and removes them based on information gleaned from IGMP messages. The forwarding of actual multicast data flows is always based on the destination MAC address and the CAM contents. Multicast will be forwarded only through ports with matching multicast CAM entries (and through mrouter ports), also meaning that with no mrouter ports and no ports with matching CAM entries, the traffic will be dropped. As an exception, traffic to 0100.5e00.00xx is always flooded through all ports in the ingress VLAN.


Catalyst 2960 and 3560 platforms behaved in a more complex way. Again, the scenario was the same - streaming traffic to 239.1.2.3 but encapsulated in MAC frames toward 0100.5e71.7273. Surprisingly, the stream was flooded to all ports in the ingress VLAN! After ascertaining that the basic IGMP Snooping works and that properly addressed stream is delivered only to the proper receiver, this proved that Catalyst 2960 and 3560 somehow do pay attention to the destination IP address of a multicast packet. I was not entirely sure how, though. One thing was clear, though: If the destination MAC address in the frame is not congruent with the IP address in the packet, these switches do not risk trusting any of these addressing information because it is not clear which one is correct, and so they fall back to flooding the multicast. Interesting - but clever!

Furthermore, I had a host subscribed to 239.113.114.115. I started streaming to 239.241.114.115 and had it encapsulated into frames toward 0100.5e71.7273. This MAC address is congruent with both these multicast IP addresses, so if 2960 and 3560 based their forwarding on MAC addresses, the host subscribed for 239.113.114.115 would be receiving even the stream to 239.241.114.115. However, the receiver did not receive any multicast packets of this stream. This proved to me that the IGMP Snooping in 2960 and 3560 works on a different level: It makes its forwarding decisions based on the destination IP address, not on destination MAC addresses, thereby making precise decisions about forwarding the multicast stream. That would also explain why 2960 and 3560 switches do not support the show mac address-table multicast command - it exists but it shows an empty output, because the multicast forwarding is no longer based on destination MAC addresses on these switch platforms. As a side note, on the 2950, this command works nicely.

My next test was how would this switch handle traffic whose destination MAC was in the 0100.5e00.00xx range (link-local multicast). Streaming packets to 224.0.0.224 with destination MAC of 0100.5e00.00e0 (congruent addressing) caused the switch to flood the stream through all ports in the ingress VLAN because it was obviously a link-local multicast that had to be flooded. However, packets to 225.0.0.224 with the same destination MAC address (congruent again) were not flooded - they were delivered only to hosts that have subscribed specifically to 225.0.0.224. This further confirmed to me that 2960 and 3560 based their multicast forwarding on the destination IP address, not on destination MAC address, and it was nice to see that the often-mentioned problem with poor choice of IP multicast groups that map to the 0100.5e00.00xx range and so get flooded does not exist with these newer switches anymore. Of course, if I encapsulated an incongruently addressed IP packets to frames toward 0100.5e00.00xx then the traffic was flooded, but I would surmise that this flooding was caused by the incongruency in the addressing, not because of the particular MAC address from the link-local scope, consistently with the behavior with incongruent addressing seen earlier.

I went even further and asked myself: Does the switch actually check that the IP packet in the frame is valid? Alternatively, does the switch care that frames with 0100.5E<0-7>x.xxxx should only be carrying IPv4 packets?

So I've done two additional experiments: I have streamed a flow toward a MAC address in the 0100.5E<0-7>x.xx scope but I have set the EtherType to 0x0801 (a non-IPv4 value). The switch flooded this traffic indiscriminately. Then, I have streamed a properly and congruently addressed flow but with IP checksum set to an incorrect value. Again, the stream was flooded indiscriminately.

Catalyst 2960 and 3560 with IGMP Snooping create multicast forwarding entries based on precise destination IP addresses. If the destination MAC and IP addresses in a multicast frame are congruent, the frame will be forwarded based on the destination IP address only to the receiver that has explicitly subscribed for this particular IP multicast group (and through mrouter ports). As an exception, traffic to 224.0.0.0/24 is flooded. This flooding, however, does not affect any other groups that map to the 0100.5E00.00xx range. If the MAC/IP addressing is incongruent, or if the frame toward 0100.5E<0-7>x.xxxx does not carry an EtherType of 0x0800, or if the IP packet checksum is invalid, the traffic is flooded.

Summing up

To sum up the observations and experiment results succintly (for more details, see above):

  1. Naive Layer2 switches flood all multicast traffic indiscriminately and do not care about possible inconsistencies in MAC and IP addressing.
  2. Routers process and forward received multicast IP packets according to usual multicast routing rules as long as their NIC decides to accept an incoming frame. Whether the incoming frame is destined toward a proper multicast MAC address, or any other multicast, unicast, or broadcast address the NIC listens to is irrelevant.
  3. Catalyst 2950 switches with IGMP Snooping forward multicast traffic based on destination MAC addresses, ignoring frame payload entirely. Multicast forwarding MAC entries in CAM pointing out ports toward correct receivers are managed by IGMP Snooping that adds or removes corresponding MAC addresses in the 0100.5e<0-7>xx.xxxx range based on gleaned IGMP messaging. Traffic to 0100.5e00.00xx is always flooded.
  4. Catalyst 2960 and 3560 with IGMP Snooping forward multicast traffic based on destination IP addresses, provided that the destination IP and MAC address are congruent. IGMP Snooping manages the list of IP groups and interfaces where particular receivers have joined or left these groups. In the case of MAC/IP incongruency, or in the case of invalid IP header checksum, or in the case of a frame toward 0100.5e<0-7>xx.xxxx having its EtherType different from 0x0800, the traffic is flooded. Traffic to 224.0.0.0/24 is always flooded.

Hopefully, this helps to lift the cloud from some of the intricate details behind IP multicast forwarding and IGMP Snooping.

Best regards,
Peter

6 Comments
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: