The IS-IS (L2) routing table entry lacks inbound interface information, so multicast traffic cannot be forwarded based only on the (*, G) table.

Question

Options

• ATRUE
• BFALSE

• A
  16% (6)
• B
  84% (32)

Explanation

B is correct because the stated conclusion does not follow - IS-IS L2 routing provides sufficient information for multicast forwarding via RPF (Reverse Path Forwarding). While IS-IS L2 table entries express outbound interface and next-hop data rather than an explicit "inbound interface" field, the RPF mechanism uses the unicast routing table in reverse: the outbound interface toward a source or Rendezvous Point (RP) in the unicast table becomes the expected inbound (RPF) interface for multicast. Therefore, (*, G) shared-tree entries, combined with IS-IS-derived RPF lookups toward the RP, are sufficient to make multicast forwarding decisions.

Why A (TRUE) is wrong: It incorrectly treats the absence of an explicit inbound-interface label in IS-IS L2 entries as a fatal gap. The RPF lookup fills that role dynamically - the router doesn't need a separate inbound field if it can derive the correct interface from the existing route to the RP.

Memory tip: Think of RPF as "unicast routing run backwards." Whatever protocol populates your unicast table - IS-IS, OSPF, BGP - the route to the source or RP tells you from which interface multicast traffic should legitimately arrive. If you remember "RPF = unicast in reverse," you'll instantly see why any unicast protocol (including IS-IS L2) can support (*, G) multicast forwarding.

No community discussion yet for this question.