A university SD-Access fabric delivers lecture video to many buildings, with large numbers of concurrent receivers spread across most fabric edge nodes. The routed underlay supports multicast with PIM-SSM, and the design must offload packet replication from the fabric edge and border nodes. Which SD-Access multicast design should the designer choose?

Native multicast is the right choice because the stem describes dense receiver sets across most edge nodes, a multicast-capable PIM-SSM underlay, and a need to offload replication from edge and border nodes. In native mode, the fabric maps overlay groups to underlay SSM groups so the routed underlay builds distribution trees and replicates packets in the network, rather than having one node send a unicast VXLAN copy per receiving edge. Head-end replication fails by concept because the ingress node must generate a separate copy for each receiving edge; although simple and free of underlay multicast state, it loads the border and edge nodes the design aims to relieve. Mixing head-end and native replication per group fails because SD-Access does not offer that per-group choice: replication is selected per fabric site, and using native multicast on one virtual network means head-end replication cannot be used for another virtual network in that site. PIM-SSM with static source mapping in the overlay and a unicast-only underlay fails because source mapping and IGMPv3 handling determine who may join, but do not provide packet replication; the fabric still needs head-end or native underlay replication. Exam caveat: native multicast requires SSM multicast in the underlay, whereas head-end replication avoids underlay multicast state, so choose based on receiver density and underlay capability. Practical check: confirm the fabric site's replication mode in Catalyst Center, then verify underlay mroute state on border and edge nodes during a peak lecture.