352-011 · Question #89
Refer to the exhibit. A new IPv4 multicast-based video-streaming service is being provisioned. During the design- validation tests, you realize that the link between the two buildings is carrying…
The correct answer is D. Change the IPv4 multicast group address such that it excludes the usage of link-local MAC. Option D is correct because IPv4 multicast addresses in the 224.0.0.0/24 range map to link-local Layer 2 MAC addresses (01:00:5E:00:00:xx), and IEEE 802.1D-compliant switches are hardcoded to flood these frames to all ports, completely bypassing IGMP snooping. Moving the…
Question
Refer to the exhibit. A new IPv4 multicast-based video-streaming service is being provisioned. During the design- validation tests, you realize that the link between the two buildings is carrying multicast traffic even when there are no receivers connected to the switch in Building B and despite IGMP snooping being enabled on both Layer 2 switches and IGMPv2 runs on the hosts. Which design change will prevent the multicast traffic from being unnecessarily flooded throughout the campus network?
Exhibit
Options
- AEnable PIM snooping on both Layer 2 switches.
- BEnable multicast storm control on the link between Switch 1 and Switch 2.
- CUse static Layer 2 MAC forwarding entries on Switch 1.
- DChange the IPv4 multicast group address such that it excludes the usage of link-local MAC
- EEnsure that Switch 1 is an IGMP querier.
How the community answered
(31 responses)- A10% (3)
- B6% (2)
- C3% (1)
- D65% (20)
- E16% (5)
Explanation
Option D is correct because IPv4 multicast addresses in the 224.0.0.0/24 range map to link-local Layer 2 MAC addresses (01:00:5E:00:00:xx), and IEEE 802.1D-compliant switches are hardcoded to flood these frames to all ports, completely bypassing IGMP snooping. Moving the multicast group address out of this range ensures IGMP snooping can actually suppress forwarding to ports with no registered receivers.
Why the distractors fail:
- A (PIM snooping): PIM snooping tracks Layer 3 PIM join/prune messages between routers - it doesn't solve a Layer 2 flooding problem caused by link-local MAC addresses, and there's no indication PIM is even in use here.
- B (Multicast storm control): Storm control rate-limits traffic but doesn't prevent flooding - it's a band-aid that doesn't fix the root cause.
- C (Static MAC forwarding): While this could manually restrict which ports receive multicast, it's an operational workaround requiring constant maintenance, not a scalable design fix.
- E (IGMP querier): A missing querier could cause IGMP snooping table entries to expire (causing flooding), but the scenario already confirms IGMP snooping is enabled and functioning - the issue is that link-local MACs are flooded unconditionally regardless of querier state.
Memory tip: Think "224.0.0.x = always floods" - the last octet of addresses in 224.0.0.0/24 directly maps to the last byte of a link-local MAC, and switches treat these like broadcast traffic. If IGMP snooping "isn't working," always check if the group address is in that reserved /24 range.
Topics
Community Discussion
No community discussion yet for this question.