IGMP snooping is a Layer 2 mechanism that constrains multicast traffic at the VLAN level. By default, a Layer 2 switch floods multicast frames to all ports within a VLAN. With IGMP snooping enabled, the switch passively inspects (snoops) the IGMP control plane messages, specifically IGMP Membership Reports (Joins) and Leave messages, exchanged between hosts (receivers) and the multicast router. Based on this information, the switch builds a multicast forwarding database that maps multicast group addresses to the specific ports where interested receivers are connected. Consequently, it forwards multicast traffic only to these ports, effectively eliminating unnecessary flooding to ports without active listeners.

A. The switch populates its forwarding table with multicast group addresses and their associated ports, not the multicast source addresses.

B. This describes the behavior of an IGMP proxy, which is a distinct feature where the device actively participates in the IGMP protocol, rather than passively listening.

D. The switch inspects only the IGMP control messages to learn group memberships. Inspecting all multicast data traffic would be highly inefficient and is not how the mechanism works.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, "IGMP Snooping" Section: "IGMP snooping is a feature that allows a switch to 'listen in' on the IGMP conversation between hosts and routers. When IGMP snooping is enabled on a switch, it examines all IGMP packets that are sent between hosts and multicast routers to determine which hosts are interested in receiving multicast traffic from a particular group. The switch then uses this information to build a map of which links need which multicast streams. Multicast traffic is then forwarded only to the links that have hosts that are interested in receiving the traffic." (Document ID: 3HE 17193 AAAD TQZZA, Part of the 7750 SR and 7950 XRS documentation suite).

2. RFC 4541, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", Section 2.1.1: "A snooping switch must examine IGMP messages between hosts and routers to determine the multicast group membership of the hosts attached to its ports... Based on this information, the switch can then forward multicast traffic only to the ports that have interested receivers." (This RFC provides the foundational principles for IGMP snooping behavior).

The Protocol Independent Multicast (PIM) Bootstrap Router (BSR) election is determined by the BSR priority value. The candidate router with the numerically highest priority is elected as the BSR for the domain. In this scenario, Router B is configured with a priority of 100, which is the highest value among all candidates (Router A: 10, Routers C & D: default 0). Therefore, Router B is elected as the BSR. The IP address is only used as a tie-breaker if two or more routers share the same highest priority value, which is not the case here.

A. Router A is not elected because its BSR priority of 10 is lower than Router B's priority of 100.

C. Router C is not elected because its default priority of 0 is lower than the priorities of Router A and Router B.

D. Router D is not elected because the highest IP address is a secondary tie-breaker, and its lower priority (0) disqualifies it from the primary election criteria.

1. IETF RFC 5059, "Bootstrap Router (BSR) Mechanism for PIM": Section 3.1, "BSR Election", states: "The BSR election is based on the BSR priority field that is included in the Bootstrap message. A C-BSR with a higher BSR priority is preferred over a C-BSR with a lower BSR priority. If the BSR priorities are equal, then the C-BSR with the higher BSR IP address is preferred."

2. Nokia 7750 SR OS R21.10.R1 Services Guide: In the "PIM" chapter, section "Bootstrap Router", it is specified that "The BSR is elected from the candidate BSRs. The election is based on the BSR priority. If the priorities are equal, the BSR with the highest IP address is elected." The guide also confirms the default priority is 0.

The command output show router pim bootstrap displays the status of the PIM Bootstrap Router (BSR) mechanism. The key indicators in this exhibit are the PIM Bootstrap State which is Bootstrap Router, and the Candidate BSR State which is Elected BSR. Furthermore, the RPF Neighbor is listed as Local, which signifies that this router is the origin of the Bootstrap Messages (BSMs) for the domain. A non-BSR router would show a different state (e.g., Accept BSMsg) and would list the IP address of an upstream router as its RPF Neighbor. This combination of output fields uniquely identifies the router as the one that has won the BSR election and is currently performing the BSR function.

A. Any router in the PIM multicast domain: A non-BSR router would display a different state and would have a non-local RPF neighbor from which it receives Bootstrap Messages.

B. Only from the Candidate-RP: This command displays BSR information, not Candidate-RP (C-RP) status. A C-RP advertises to the BSR; it is not necessarily the BSR itself.

C. Only from the Candidate-BSR: While this router is a Candidate-BSR (C-BSR), this option is not specific enough. A C-BSR that lost the election would show a different state, such as Not Elected.

1. Nokia 7750 SR OS R19.10.R1 Router Configuration Guide, Part: PIM, Section: PIM Command Reference

Reference: In the description for the show router pim bootstrap command, the output fields are explained. The Candidate BSR State field value of Elected BSR indicates that "The local router is the elected BSR." The RPF Neighbor field showing Local confirms the BSMs originate from this router, which is only true for the elected BSR.

2. Nokia 4A0-108 Courseware, Module: IP Multicast Routing

Reference: The course material on PIM-SM bootstrap mechanism details the BSR election process. It explains that only the router that wins the election will assume the Bootstrap Router state and originate Bootstrap Messages. The show router pim bootstrap command on the elected BSR will reflect this status with fields like Candidate BSR State: Elected BSR and RPF Neighbor: Local.

The PIM Bootstrap Router (BSR) mechanism is designed to elect a single, unique BSR for an entire PIM domain. Candidate-BSRs (c-BSRs) exchange Bootstrap Messages (BSMs) containing their priority and IP address. Through an election process, the c-BSR with the highest priority (or highest IP address as a tie-breaker) is chosen as the active BSR. In a stable, converged network, all routers will agree on this single BSR. The existence of multiple elected BSRs would indicate a network partition or a state of non-convergence, contradicting the premise of a "converged multicast network."

A. A router can be configured as both a candidate-BSR and a candidate-RP. This is a common configuration where a router participates in the BSR election and also advertises itself as an available RP.

B. A router can be configured as a candidate-BSR while also being configured as a static RP. The two mechanisms (dynamic BSR discovery and static RP configuration) can coexist on the same device.

C. A router can be configured as a candidate-RP for dynamic discovery while also being configured as a static RP. These are distinct configuration roles that are not mutually exclusive on a single router.

E. The BSR's primary function is to collect advertisements from multiple candidate-RPs and distribute a consolidated RP-set to all routers. This allows for multiple active RPs for different group ranges or for redundancy.

1. Nokia 7750 SR OS Release 19.10.R1 Multicast Routing Protocols Guide, Page 118, Section "PIM Bootstrap Router": "In a PIM domain, a single router is elected as the BSR from a set of candidate BSRs. The BSR is responsible for collecting C-RP advertisements and disseminating the group-to-RP mapping information in Bootstrap messages (BSMs)." This confirms a single BSR is elected and that it collects information from potentially multiple C-RPs.

2. RFC 5059: Bootstrap Router (BSR) Mechanism for PIM, Section 1, Introduction: "With BSR, a single router in a PIM domain is elected as the Bootstrap Router (BSR) from a set of candidate BSRs." This statement from the governing standard explicitly states that the outcome of the election is a single BSR.

3. RFC 5059: Bootstrap Router (BSR) Mechanism for PIM, Section 3.1, BSR Election: "The BSR election procedure selects a single BSR for a PIM domain. Each C-BSR, upon receiving a BSM, compares its own BSR priority and address with that of the BSR that originated the received BSM..." This details the mechanism that ensures only one BSR is elected.

The statement that MP-BGP is used for customer multicast group signaling is misleading and therefore considered false in this context. While the exhibit shows C-Mcast Signaling: BGP, this refers to the mechanism used between PE routers to advertise customer multicast (C-multicast) state across the provider's core. The actual signaling for group membership originating from the customer's network (from CE to PE) is typically done using PIM or IGMP. The PE router learns the customer's multicast state via these protocols and then uses MP-BGP to propagate this information to other PEs. Therefore, BGP is not the originating signaling protocol for customer groups, but rather a transport for that state information between PEs.

A. This is true. The exhibit output explicitly shows I-PMSI Tunnel: GRE and S-PMSI Tunnel: GRE, indicating both use GRE tunnels.

B. This is true. The exhibit clearly states I-PMSI Auto-Discovery: BGP and S-PMSI Auto-Discovery: BGP.

D. This is true. The exhibit line S-PMSI Group Address directly shows the configured range as 232.10.10.0/24.

1. Nokia 7750 SR OS Services Guide, Release 21.10.R1, Section: BGP-MVPN for VPLS.

Reference: "The PE routers run an instance of PIM or IGMP snooping that learns of C-multicast streams and receivers that are active in the VPLS. This information is then advertised by BGP to all other PE routers that are part of the same VPLS service."

Comment: This official documentation distinguishes between the learning of customer multicast state (via PIM/IGMP) and the advertisement of that state between PEs (via BGP), supporting the reasoning that BGP is not the originating signaling protocol.

2. RFC 6514: BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs, Section 5: C-Multicast Routing.

Reference: "When a PE router that is attached to a particular VPN site learns, via a C-PIM instance, of a multicast source that is active within that site, it may originate a BGP update containing a C-multicast route."

Comment: This IETF standard, which defines BGP-MVPN, clarifies that the PE router learns of customer multicast activity via a Customer-PIM (C-PIM) instance and then originates a BGP update. This confirms that PIM is the customer-facing signaling protocol, while BGP is used for inter-PE communication.

The mapping of an IPv4 multicast address to an Ethernet MAC address follows the standard defined in IETF RFC 1112. The Internet Assigned Numbers Authority (IANA) has allocated the MAC address prefix 01-00-5E for this purpose. The mapping procedure is as follows:

1. The first 24 bits of the MAC address are the fixed prefix 01-00-5E.

2. The 25th bit of the MAC address is always set to 0.

3. The remaining 23 bits of the MAC address are copied from the lower 23 bits of the 32-bit IPv4 multicast address.

For the IP address 239.33.42.107:

The lower 23 bits are derived from 33.42.107.

The second octet 33 (00100001) becomes 0x21 after masking the most significant bit (00100001 -> 0x21).

The third octet 42 is 0x2A.

The fourth octet 107 is 0x6B.

Combining these results in the MAC address 01-00-5E-21-2A-6B.

A. 01-00-5e-a1-2a-6b: The value a1 is incorrect. It would correspond to an IP second octet of 161 (10100001), not 33 (00100001).

C. 01-00-5e-21-2c-6c: The values 2c and 6c are incorrect hexadecimal conversions for the IP octets 42 and 107, respectively.

D. 00-01-5e-a1-2a-6b: The prefix 00-01-5E is incorrect. The IANA-specified prefix for IPv4 multicast is 01-00-5E.

E. 00-01-5e-21-2a-6b: The prefix 00-01-5E is incorrect. The standard prefix is 01-00-5E.

F. 00-01-5e-a1-2c-6b: This option has an incorrect prefix and incorrect hexadecimal values for the IP octets.

1. IETF RFC 1112, "Host Extensions for IP Multicasting": Section 6.4, "IP Multicast-Address to Ethernet-Address Mapping". This document specifies the standard mapping rule: "An IP host group address is mapped to an Ethernet multicast address by placing the low-order 23 bits of the IP address into the low-order 23 bits of the Ethernet multicast address 01-00-5E-00-00-00."

2. Nokia 7750 SR OS Services Guide, Release 19.10.R1: In the "IP Multicast" chapter, under the "Layer 2/3 Multicast Forwarding" section, the guide states: "The IANA owns an Ethernet MAC address block, 01:00:5e, for multicast... The 23 bits from the IP multicast address are mapped to the 23 variable bits of the MAC address." This confirms the mapping principle used in Nokia systems.

3. Kurose, J. F., & Ross, K. W. (2017). Computer Networking: A Top-Down Approach (7th ed.): Chapter 4, Section 4.6.1, "The Internet's Network-Layer Forwarding Architecture". The textbook explains that for IP multicast, the low-order 23 bits of the IP multicast address are placed in the low-order 23 bits of a special range of Ethernet addresses starting with 01:00:5E.

The command output in the exhibit provides direct information about the signaling and discovery mechanisms for MVPN service 100. The line C-Mcast Signaling: BGP indicates that BGP is used to exchange customer multicast routing information (C-flows) between Provider Edge (PE) routers. The line Auto-discovery: BGP indicates that BGP is also used for the discovery of other PEs participating in the same MVPN instance. This architecture is characteristic of Next-Generation MVPN (NG-MVPN), where BGP extensions handle both PE auto-discovery and the signaling of customer multicast state, replacing the need for PIM in the provider core for these functions.

A. This is incorrect. The exhibit clearly shows Auto-discovery: BGP, meaning BGP, not PIM, is used to discover PEs.

B. This is incorrect. The exhibit explicitly states C-Mcast Signaling: BGP, meaning BGP, not PIM, is used for customer multicast signaling.

D. This is incorrect. The exhibit shows that BGP is used for both functions, not PIM. PIM may be used within the customer network (C-PIM), but not for signaling or discovery between PEs in this configuration.

1. Nokia 7750 SR and 7450 ESS Services Guide, Release 21.10.R1, Document Part Number: 3HE 17661 AAAC TQZZA, Section: BGP-Based MVPN.

This section details the NG-MVPN architecture, stating, "BGP is used for auto-discovery and to transport C-multicast routing information." It further explains that BGP auto-discovery routes are used for PE discovery and BGP C-multicast routes are used to signal C-multicast information. The fields C-Mcast Signaling and Auto-discovery in the show service id mvpn command output directly correspond to these functions.

2. Nokia 7750 SR and 7450 ESS Services Guide, Release 21.10.R1, Document Part Number: 3HE 17661 AAAC TQZZA, Section: MVPN Command Reference, show service id mvpn command.

The documentation for this command describes the output fields. It specifies that C-Mcast Signaling displays the protocol used to signal customer multicast information (BGP or PIM) and Auto-discovery displays the protocol used for PE auto-discovery (BGP or PIM). The exhibit's output of "BGP" for both fields confirms the scenario in the correct answer.

In a Draft Rosen Multicast VPN (MVPN), the Inclusive Provider Multicast Service Interface (I-PMSI), also known as the Default Multicast Distribution Tree (Default-MDT), is used to flood customer multicast traffic to all PE routers participating in a specific VPN. To achieve this, a single, pre-configured multicast group address from the provider's address space is assigned to the I-PMSI for that VPN. When an ingress PE router receives a customer multicast packet, it encapsulates it into a provider packet (typically GRE). The destination IP address of this outer provider packet is set to the configured I-PMSI multicast group address, ensuring it is distributed through the provider's PIM-enabled core to all other PEs in the same MVPN.

A. The destination group address of the customer packets is the inner header's destination and is not used for routing across the provider core.

C. The system IP address of a receiving PE is a unicast address; an I-PMSI requires a point-to-multipoint transport using a multicast address.

D. A multicast group address selected from a range is a mechanism used for a Selective-PMSI (S-PMSI), not the all-encompassing I-PMSI.

1. RFC 6037: Cisco Systems' Solution for Multicast in BGP/MPLS IP VPNs.

Section 3, "Building the Default-MDT": "Each PE router that is a member of a given VRF is configured with a multicast address from the provider's address space. This address, called the 'Default-MDT group address', must be the same for all PE routers that are members of that VRF."

Section 4, "Sending Multicast Packets to Remote PE Routers": "When a PE router receives a multicast packet from a site, it encapsulates the packet... The destination address of the encapsulating... packet is the Default-MDT group address for the VRF."

2. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Services Guide, Release 21.10.R1.

Chapter: Multicast VPN, Section: Rosen MVPN: "The default-MDT uses a specific P-multicast group address to build a P-tunnel to flood C-multicast traffic for a specific MVPN... When C-multicast traffic is received on an ingress PE, the ingress PE encapsulates the C-multicast packets and forwards them over the P-network to the P-multicast group address of the default-MDT."

IGMP version 3 (IGMPv3), defined in RFC 3376, introduced significant enhancements to support Source-Specific Multicast (SSM). A primary change was modifying the Membership Report message to include a list of source addresses. This allows a host to signal its interest in receiving multicast traffic from specific sources (INCLUDE mode) or from all sources except specific ones (EXCLUDE mode).

To accommodate these source-specific reports, the report suppression mechanism, which was a feature of IGMPv1 and v2, was eliminated. In IGMPv3, all hosts must send their own reports, as different hosts on the same segment might have different source filter requirements for the same multicast group.

A. Leave group message: The Leave Group message was introduced in IGMP version 2 (RFC 2236) to allow hosts to explicitly signal their departure from a group, reducing leave latency.

C. IGMP snooping: IGMP snooping is a Layer 2 switch feature, not a feature of the IGMP protocol itself. It optimizes multicast traffic by forwarding it only to ports with interested receivers.

D. TTL of 1 for IGMP messages: Setting the IP Time-to-Live (TTL) to 1 for IGMP messages has been a standard practice since IGMPv1 to ensure messages are confined to the local subnet.

1. Internet Engineering Task Force (IETF) RFC 3376, "Internet Group Management Protocol, Version 3":

Section 1, Introduction: "The new version, IGMPv3, adds support for 'source filtering', that is, the ability for a system to report interest in receiving packets only from specific source addresses... To support source filtering, the IGMP protocol is modified..." This directly supports option E.

Section 4.2.12, "Sending Membership Reports": "The Report Suppression mechanism of IGMPv1 and IGMPv2 is no longer used. In IGMPv3, all reports are sent to all multicast routers..." This directly supports option B.

2. Internet Engineering Task Force (IETF) RFC 2236, "Internet Group Management Protocol, Version 2":

Section 2, "Protocol Description": This section details the introduction of the "Leave Group Message," confirming that this feature belongs to IGMPv2, not IGMPv3.

3. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Layer 3 Services Guide: Multicast, Release 21.10.R1:

Chapter: "IGMP", Section: "IGMP Version 3 (IGMPv3)": "IGMPv3 adds the ability for a host to signal the group from which it wants to receive multicast traffic, and the source or sources from which it does not want to receive multicast traffic. This is called source-filtering." This supports option E. The document also implicitly confirms the removal of report suppression by describing the new reporting mechanism required for source filtering.

The Bootstrap Router (BSR) protocol is a dynamic mechanism used in Protocol Independent Multicast - Sparse Mode (PIM-SM) for distributing Rendezvous Point (RP) information. Multiple routers can be configured as candidate-BSRs (C-BSRs), but they undergo an election process. Each C-BSR advertises its priority, and the candidate with the highest priority is elected as the single BSR for the entire PIM domain. If priorities are equal, the highest IP address serves as a tie-breaker. This election ensures that there is only one active BSR at any time, providing a single, consistent source of RP-set information to all routers in the domain.

A. A router can be configured as a static RP for specific multicast groups while also being configured as a BSR candidate for dynamic RP discovery for other groups.

B. A single router can be configured to function as both a candidate-RP (C-RP) and a candidate-BSR (C-BSR) simultaneously. This is a common network design choice.

C. A PIM domain is designed to support multiple active RPs. The BSR mechanism distributes a set of available RPs, and routers map different multicast groups to different RPs.

1. Nokia 7450 ESS, 7750 SR, 7950 XRS, and VSR Multicast Routing Protocols Guide, Release 21.10.R1

For Correct Answer (D): In the "PIM" chapter, section "Bootstrap Router (BSR)", it states: "Each C-BSR collects BSMs and elects a single BSR for the PIM domain using an election algorithm. The C-BSR with the highest priority is elected as the BSR. If all C-BSRs have the same priority, the C-BSR with the highest IP address is elected as the BSR." (This confirms the election of a single BSR).

For Incorrect Answer (C): In the "PIM" chapter, section "Rendezvous Point (RP)", it describes the RP-Set: "The elected BSR builds a set of C-RPs, called the RP-Set, and includes the RP-Set in the BSMs that it periodically originates." (This confirms the existence of a set of multiple RPs).

For Incorrect Answer (B): The configuration examples within the "PIM" chapter demonstrate that the bootstrap-candidate and rp-candidate commands can be configured under the same configure>router>pim context, indicating a single router can perform both roles.

2. RFC 5059: Bootstrap Router (BSR) Mechanism for PIM

For Correct Answer (D): Section 3.1, "BSR Election," details the process where all BSR candidates in a domain elect a single BSR. It specifies, "The BSR election procedure is simple: a candidate BSR includes its own priority and address in the Bootstrap messages it originates. A C-BSR which hears about a BSR with a higher priority value... ceases to send Bootstrap messages... This ensures that eventually only one BSR is left active in the domain."