{"id":217,"date":"2026-06-15T00:00:00","date_gmt":"2026-06-14T20:30:00","guid":{"rendered":"https:\/\/www.anynet.ir\/blog\/%d8%b3%d8%b1%d9%88%db%8c%d8%b3%d9%87%d8%a7%db%8c-%da%86%d9%86%d8%af%d9%be%d8%ae%d8%b4%db%8c-multicast-%d8%a8%d8%b1-%d8%a8%d8%b3%d8%aa%d8%b1-%d9%87%d8%b3%d8%aa%d9%87%d9%87%d8%a7%db%8c-srv6-ipv6-en\/"},"modified":"2026-06-15T00:00:00","modified_gmt":"2026-06-14T20:30:00","slug":"%d8%b3%d8%b1%d9%88%db%8c%d8%b3%d9%87%d8%a7%db%8c-%da%86%d9%86%d8%af%d9%be%d8%ae%d8%b4%db%8c-multicast-%d8%a8%d8%b1-%d8%a8%d8%b3%d8%aa%d8%b1-%d9%87%d8%b3%d8%aa%d9%87%d9%87%d8%a7%db%8c-srv6-ipv6-en","status":"publish","type":"post","link":"https:\/\/www.anynet.ir\/blog\/en\/%d8%b3%d8%b1%d9%88%db%8c%d8%b3%d9%87%d8%a7%db%8c-%da%86%d9%86%d8%af%d9%be%d8%ae%d8%b4%db%8c-multicast-%d8%a8%d8%b1-%d8%a8%d8%b3%d8%aa%d8%b1-%d9%87%d8%b3%d8%aa%d9%87%d9%87%d8%a7%db%8c-srv6-ipv6-en\/","title":{"rendered":"Multicast Services over SRv6 \/ IPv6 Cores"},"content":{"rendered":"
<\/div>\n
\n
<\/div>\n<\/div>\n
\n
\n
\n

Introduction<\/h2>\n

Service provider cores are steadily moving toward IPv6-only transport and Segment Routing over IPv6 (SRv6) services, but multicast cannot be treated as an afterthought. The goal is to carry existing multicast VPN use cases forward without introducing a separate multicast transport model or SRv6-specific replication behavior.<\/p>\n

The approach described here keeps the provider multicast tree native to IPv6 and uses BGP Multicast VPN (MVPN) for service signaling. SRv6 remains the unicast and service context; multicast forwarding is handled by PIMv6-SSM and IP-in-IP encapsulation.<\/p>\n

This article is structured in three parts. The first covers Multicast VPN fundamentals: core tree types, Multicast Distribution Tree (MDT) mechanisms, and PMSI concepts that apply to any MVPN deployment regardless of transport. The second presents Cisco’s multicast architecture for SRv6 \/ IPv6 cores, showing how these fundamentals are realized using native IPv6 multicast, PIMv6-SSM, and BGP MVPN over an IPv6 core used for SRv6 services. The third provides sample configuration and verification tied to a reference topology, so the reader can move from concept to deployment.<\/p>\n

Why Multicast Matters<\/h2>\n

Multicast workloads continue to grow across service provider, enterprise, and government networks, driven by live media, IPTV, financial market data, surveillance, and IoT. As these networks migrate to SRv6, multicast services must migrate with them.<\/p>\n

The architecture described in this article ensures multicast carries forward into IPv6\/SRv6 networks natively, without parallel infrastructure or protocol overlays outside the IPv6 stack.<\/p>\n

Multicast VPN Fundamentals<\/h2>\n

Before examining the IPv6-native solution, it is essential to understand the foundational Multicast VPN concepts that underpin the architecture. This section covers the building blocks, core tree types, and MDT mechanisms that any multicast VPN deployment relies on, regardless of the underlying transport.<\/p>\n

Core Trees<\/h3>\n

In an MVPN architecture, provider edge (PE) routers must deliver customer multicast traffic across the provider core without requiring core routers to hold per-VPN state. This is achieved through core trees: provider-level multicast distribution trees that carry encapsulated customer traffic between PEs.<\/p>\n

The core tree is formally referred to as a Provider Multicast Service Interface (PMSI). The PMSI abstracts the provider core as a multicast-capable tunnel connecting PEs participating in a given VPN.<\/p>\n

Point-to-Multipoint Trees<\/h3>\n

A point-to-multipoint (P2MP) tree has a single root, the ingress PE, and multiple leaves, the egress PEs with interested receivers. Unlike point-to-point tunnels that require a separate path per destination, a P2MP tree replicates traffic at branching points in the core, delivering one copy of each packet to all interested receivers efficiently.<\/p>\n

\"Point-to-multipoint
\nFigure 1: Point-to-multipoint (P2MP) tree with one ingress PE branching to multiple egress PEs. Core routers replicate traffic at branch points.<\/em><\/p>\n

    \n
  • The ingress PE acts as the root of the tree and sources customer multicast traffic into the core.<\/li>\n
  • Each egress PE with active receivers joins the tree as a leaf.<\/li>\n
  • Core P routers replicate traffic at branching points. They forward multicast without any awareness of the customer overlay.<\/li>\n
  • Tree construction is typically hop-by-hop using PIM joins toward the root PE’s address.<\/li>\n<\/ul>\n

    This model keeps provider core state proportional to the number of active multicast sources, not the number of customer flows.<\/p>\n

    PMSI Types<\/h3>\n

    \"PMSI
    \nFigure 2: The two primary PMSI categories: I-PMSI, also known as Default MDT, connects all PEs, while S-PMSI, also known as Data MDT, connects only interested PEs.<\/em><\/p>\n

    The MVPN framework defines several PMSI types. The two most relevant are:<\/p>\n\n\n\n\n\n\n
    PMSI type<\/th>\nTree scope<\/th>\nUsed for<\/th>\n<\/tr>\n<\/thead>\n
    Inclusive PMSI (I-PMSI)<\/td>\nConnects all PEs in a VRF<\/td>\nDefault MDT<\/td>\n<\/tr>\n
    Selective PMSI (S-PMSI)<\/td>\nConnects only PEs with active receivers<\/td>\nData MDT<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

    The I-PMSI is always present and carries control signaling and low-rate multicast traffic. The S-PMSI is created on demand to optimize high-rate flows by delivering them only to PEs that need them.<\/p>\n

    Default MDT<\/h3>\n

    The Default MDT is the foundational tree that connects all PE routers participating in a multicast-enabled VPN Routing and Forwarding (VRF) instance. It is always active and serves as the baseline transport for customer multicast traffic and, in PIM-signaled models, customer multicast control messages.<\/p>\n

    When a VRF is configured with multicast, each PE is assigned a multicast group address for the Default MDT. All PEs in that VRF join this group, forming a shared multicast tree across the provider core.<\/p>\n

    From the perspective of PIM running in the customer VRF overlay, the Default MDT can act like a virtual LAN where all PEs appear as directly connected PIM neighbors. In the BGP C-multicast model validated in this article, PE discovery and customer multicast joins are signaled with BGP MVPN; the MDT provides the provider tunnel used to carry encapsulated customer multicast traffic.<\/p>\n

    Key characteristics:<\/p>\n

      \n
    • Always on<\/strong> – The Default MDT is established as soon as the VRF is configured with multicast, regardless of whether customer traffic is flowing.<\/li>\n
    • Carries baseline customer traffic<\/strong> – Customer multicast (S,G)<\/code> flows are initially forwarded on the Default MDT unless a Data MDT is triggered.<\/li>\n
    • Separates overlay signaling from transport<\/strong> – In this BGP-signaled example, PE discovery and C-multicast joins are BGP MVPN routes, while the MDT is the provider transport tree.<\/li>\n
    • Shared across address families<\/strong> – A single Default MDT group serves both IPv4 and IPv6 customer multicast within the same VRF.<\/li>\n
    • One per VRF<\/strong> – Each multicast-enabled VRF has its own Default MDT with a unique multicast group.<\/li>\n<\/ul>\n

      Because all PEs in a VRF share a single Default MDT, the provider core maintains one multicast tree per VRF, not one per customer flow. This keeps core state manageable even as the number of customer (S,G)<\/code> entries grows.<\/p>\n

      However, the Default MDT delivers traffic to all PEs in the VRF, including those without active receivers. For low-rate flows and control traffic, this overhead is acceptable. For high-bandwidth flows, the Data MDT provides a more efficient alternative.<\/p>\n

      \"Default
      \nFigure 3: Default MDT delivers multicast traffic to all PEs in the VRF. PEs without interested receivers for a given flow drop the unwanted traffic.<\/em><\/p>\n

      Data MDT<\/h3>\n

      The Data MDT addresses the efficiency limitation of the Default MDT. While the Default MDT delivers traffic to all PEs in a VRF, the Data MDT creates a selective tree that only includes PEs with active receivers for a specific customer (S,G)<\/code> flow.<\/p>\n

      \"Data
      \nFigure 4: Data MDT creates a selective P2MP tree. Only PEs with active receivers join the Data MDT; PEs without receivers cache the signaling but do not join.<\/em><\/p>\n

      The sequence is:<\/p>\n\n\n\n\n\n\n\n\n
      Step<\/th>\nFunction<\/th>\n<\/tr>\n<\/thead>\n
      1. Threshold trigger<\/td>\nThe ingress PE monitors the traffic rate for each customer (S,G)<\/code> on the Default MDT. When a flow exceeds a configurable bandwidth threshold, or immediately if configured, the ingress PE initiates a Data MDT.<\/td>\n<\/tr>\n
      2. Signaling<\/td>\nThe ingress PE advertises a BGP MVPN Type 3, S-PMSI Auto-Discovery, route to all PEs in the VRF. This route identifies the customer (S,G)<\/code> and the new multicast group to be used for the Data MDT.<\/td>\n<\/tr>\n
      3. Selective join<\/td>\nOnly egress PEs with active receivers for that (S,G)<\/code> join the new Data MDT tree in the core. PEs without receivers cache the advertisement but do not join.<\/td>\n<\/tr>\n
      4. Switchover<\/td>\nAfter a brief hold-down period, the ingress PE moves the customer (S,G)<\/code> traffic from the Default MDT onto the Data MDT. The flow is now delivered only to interested PEs.<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

      Key characteristics:<\/p>\n

        \n
      • Per-(S,G)<\/code> granularity<\/strong> – Each Data MDT carries a single customer (S,G)<\/code> flow. Data MDTs apply to source-specific trees only, not shared trees.<\/li>\n
      • On-demand creation<\/strong> – Data MDTs are created only when traffic exceeds the threshold, keeping core state minimal during low-traffic periods.<\/li>\n
      • Separate P2MP tree<\/strong> – Each Data MDT uses its own multicast group, creating an independent P2MP tree in the provider core.<\/li>\n
      • BGP-signaled<\/strong> – The Type 3 route ensures all PEs are informed of the switchover; egress PEs join autonomously based on receiver interest.<\/li>\n
      • Reversible<\/strong> – If the traffic rate drops below the threshold or receivers disconnect, the flow can move back to the Default MDT.<\/li>\n<\/ul>\n

        \"Data
        \nFigure 5: BGP IPv4 MVPN update carrying Data MDT information, including PMSI tunnel details used by the ingress PE to signal the Data MDT switchover.<\/em><\/p>\n\n\n\n\n\n\n\n\n\n
        Aspect<\/th>\nDefault MDT<\/th>\nData MDT<\/th>\n<\/tr>\n<\/thead>\n
        Scope<\/td>\nAll PEs in the VRF<\/td>\nOnly PEs with active receivers<\/td>\n<\/tr>\n
        Activation<\/td>\nAlways on<\/td>\nOn demand, threshold-based<\/td>\n<\/tr>\n
        Traffic type<\/td>\nControl and low-rate data<\/td>\nHigh-rate (S,G)<\/code> flows<\/td>\n<\/tr>\n
        Core tree<\/td>\nOne per VRF<\/td>\nOne per (S,G)<\/code> flow<\/td>\n<\/tr>\n
        Signaling<\/td>\nBGP MVPN Type 1, Auto-Discovery<\/td>\nBGP MVPN Type 3, S-PMSI A-D<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

        In a typical deployment, the Default MDT handles baseline multicast connectivity and low-bandwidth multicast flows, while high-bandwidth streams such as IPTV channels and live video feeds are offloaded to Data MDTs for efficient delivery.<\/p>\n

        BGP Auto-Discovery and Signaling<\/h3>\n

        Traditional MVPN, or Draft-Rosen, relied on PIM in the provider core for both tree construction and PE discovery. NG-MVPN, defined by RFC 6513 and RFC 6514, replaces this with BGP-based Auto-Discovery where PEs advertise their participation in a multicast VPN through BGP, eliminating the need for PIM adjacencies across the Default MDT for PE discovery.<\/p>\n

        BGP MVPN introduces two key functions:<\/p>\n

          \n
        • Auto-Discovery<\/strong> – PEs automatically learn which other PEs are enabled for multicast in a given VPN. Each PE advertises its loopback address and VPN membership via BGP, removing the need for manual configuration or PIM-based discovery.<\/li>\n
        • Customer signaling in overlay<\/strong> – Customer C-multicast Join and Prune messages are signaled via BGP rather than PIM between PEs. This means customer multicast state is carried in BGP updates as C-multicast routes, not as PIM messages flooded across the Default MDT.<\/li>\n<\/ul>\n

          Every BGP MVPN update that binds a customer multicast flow to a provider tunnel carries a PMSI Tunnel Attribute. The PTA contains two critical pieces of information:<\/p>\n

            \n
          • Tunnel type<\/strong> – Identifies the core tree protocol, such as PIM-SSM, mLDP P2MP, RSVP-TE P2MP, or IR. This tells the receiving PE how to join the provider tree.<\/li>\n
          • Tunnel identifier<\/strong> – Uniquely identifies the specific tunnel instance, such as the multicast group address for PIM-SSM or the FEC element for mLDP. This tells the receiving PE which tree to join.<\/li>\n<\/ul>\n

            The PTA connects the BGP MVPN control plane to the underlying provider multicast infrastructure. It is the bridge between the overlay signaling and the underlay tree.<\/p>\n

            The BGP MVPN address family defines seven route types in RFC 6514. The ones most relevant to this article are:<\/p>\n

              \n
            • Type 1, Intra-AS I-PMSI A-D<\/strong> – Each PE advertises its membership in a multicast VPN, establishing the Default MDT.<\/li>\n
            • Type 3, S-PMSI A-D<\/strong> – The ingress PE signals a Data MDT, binding a customer (S,G)<\/code> flow to a selective provider tunnel.<\/li>\n
            • Type 5, Source Active A-D<\/strong> – The source PE advertises that a customer multicast source is active; this is relevant when the customer VRF uses PIM-SM.<\/li>\n
            • Type 6, Shared Tree Join<\/strong> – An egress PE signals interest in a customer shared tree; this is relevant when the customer VRF uses PIM-SM.<\/li>\n
            • Type 7, Source Tree Join<\/strong> – An egress PE signals interest in a customer source tree; this is used for source-tree joins, including SSM flows.<\/li>\n<\/ul>\n

              Other MVPN route types are outside the single-AS Default MDT verification scope used in the configuration example.<\/p>\n

              SRv6 \/ IPv6 Core Architecture<\/h2>\n

              Cisco’s multicast strategy for SRv6 \/ IPv6 core networks is MVPN over an IPv6 core used for SRv6 services, using native PIMv6-SSM in the underlay and IP-in-IP encapsulation for customer traffic. In this architecture, multicast forwarding does not use SRv6 SIDs, Segment Routing Headers, or SRv6 packet formats; the provider tree is native IPv6 multicast. This leverages mature IPv6 multicast standards without requiring SRv6-specific multicast extensions. Multicast services share the same IPv6 core used for unicast and no separate multicast infrastructure is needed.<\/p>\n

              In the validation lab, SRv6 is configured so the environment represents an SRv6 L3VPN service, but multicast transport itself uses IPv6\/PIMv6, not SRv6 SID\/SRH forwarding.<\/p>\n

              The architecture builds on RFC 6513\/6514 MVPN procedures, RFC 6515 for IPv6 infrastructure addresses, RFC 8950 for advertising IPv4 NLRI with IPv6 next-hops, and RFC 7761 for PIM-SM and PIM-SSM behavior. The SRv6 service context is based on RFC 8402 and RFC 8986, while Flex-Algo path influence is covered by RFC 9350 and RFC 9502.<\/p>\n

              Design principles:<\/p>\n

                \n
              • Native IPv6 multicast<\/strong> – PIMv6-SSM builds provider trees; no new SRv6-specific mechanisms are required.<\/li>\n
              • BGP MVPN overlay<\/strong> – Customer multicast signaling occurs between PEs.<\/li>\n
              • IP-in-IP encapsulation<\/strong> – The data plane uses lightweight transport without an additional overlay shim.<\/li>\n
              • Operational simplicity<\/strong> – A consistent PIMv6-SSM MDT transport model for multicast VRF services gives operators one set of procedures to learn and one set of show commands to master, replacing the traditional mix of protocol combinations.<\/li>\n<\/ul>\n

                The approach has multi-vendor IETF support. draft-ietf-pim-multicast-over-srv6<\/code> is an active PIM Working Group document, with authors from Cisco, Juniper, Nokia, Aramco, and Verizon. As an Internet-Draft, it should be treated as work in progress while the core design continues to use existing standards-based building blocks.<\/p>\n

                Control Plane<\/h3>\n

                The multicast control plane uses a two-plane architecture:<\/p>\n

                  \n
                • BGP MVPN overlay<\/strong> – Root, Mid, and Tail PE routers exchange MVPN routes through the Route Reflector for Auto-Discovery and customer multicast signaling. No direct PE-to-PE PIM adjacencies are needed in the overlay.<\/li>\n
                • IPv6 underlay<\/strong> – The same IPv6 network used for SRv6 unicast. PIMv6-SSM runs within this underlay to build the native IPv6 multicast distribution trees. All routers participate, Root, Mid, and Tail as PEs and P1\/P2 as transit routers, but only P1 and P2 are exclusive to this layer; they have no awareness of customer VPN state.<\/li>\n<\/ul>\n

                  \"Two-plane
                  \nFigure 6: Multicast services over SRv6 \/ IPv6 cores use a two-plane architecture: BGP MVPN overlay for service signaling and IPv6 underlay with PIMv6-SSM for provider multicast transport.<\/em><\/p>\n

                  BGP Overlay Discovery<\/strong><\/p>\n

                  Using the BGP MVPN Auto-Discovery mechanism introduced earlier, each PE, Root, Mid, and Tail, advertises a Type 1 Intra-AS I-PMSI A-D route via the RR. The Type 1 route carries the PMSI Tunnel Attribute, which specifies the tunnel type, PIM-SSM, the MDT source, the PE loopback, and the MDT group, unique per VRF. At the end of this exchange, all three PEs know each other and know exactly how to build the underlay tree, but no trees are built yet.<\/p>\n

                  PIMv6-SSM Underlay Tree Build<\/strong><\/p>\n

                  Triggered by the PMSI TA received during overlay discovery, each PE reads the MDT source and group and initiates PIMv6-SSM (S,G)<\/code> joins toward the other PEs’ loopbacks. These joins propagate hop-by-hop through P1 and P2, the transit routers, and Mid, the bud node acting as both transit hop and PE, building one source-rooted P2MP tree per PE. Collectively, these per-PE trees provide bidirectional PE-to-PE MDT connectivity, while each individual tree remains rooted at a single PE. Transit routers participate in PIM but have no awareness of VPN state. This is pure native IPv6 multicast.<\/p>\n

                  At the end of control plane setup, the provider core has bidirectional PIM trees connecting all PEs, with BGP auto-discovery complete.<\/p>\n

                  \"Control
                  \nFigure 7: End of control plane setup. BGP exchange auto-discovery connects PEs through the RR, while PIMv6-SSM trees are built in the core.<\/em><\/p>\n

                  Customer Join Signaling<\/strong><\/p>\n

                  When a receiver sends an IGMP\/PIM join for a customer (S,G)<\/code>, the egress PE, such as Tail, performs a VRF Reverse Path Forwarding (RPF) lookup pointing to the ingress PE via BGP next-hop, generates a BGP MVPN Type 7 Source Tree Join route, and advertises it to the ingress PE, Root, via the RR. Root programs its VRF entry to forward that customer flow onto the Default MDT. No PIM signaling between PEs is needed, only BGP.<\/p>\n

                  Data Plane<\/h3>\n

                  Customer (S,G)<\/code> traffic arrives at Root, the ingress PE, from the CE, is encapsulated in IP-in-IPv6, and is forwarded onto the PIM-built tree. P1 and P2 forward the packet as native IPv6 multicast and never inspect the inner customer payload. At Tail, the egress PE, the outer header is stripped and the customer packet is delivered to the receiver. PEs maintain both a provider P(S,G)<\/code> entry and a customer C(S,G)<\/code> entry; transit routers forward based on P(S,G)<\/code> only.<\/p>\n

                  \"Data
                  \nFigure 8: Data plane forwarding with provider P(S,G) state for core IPv6 multicast forwarding and customer C(S,G) state for VRF delivery. Core routers forward natively; only edge PEs perform encapsulation and decapsulation.<\/em><\/p>\n

                  The encapsulation is simple IP-in-IPv6, with no GRE, MPLS, or additional tunnel header.<\/p>\n

                  \"IPv4
                  \nFigure 9: IPv4 customer traffic encapsulation using IP-in-IPv6. The provider IPv6 Next Header field is set to 4 because the inner customer header is IPv4.<\/em><\/p>\n

                  At the ingress PE, the customer IPv4 packet is encapsulated in an outer provider IPv6 header; transit routers forward natively; at the egress PE, the outer header is stripped. The Next Header<\/code> field in the provider IPv6 header must be set to 4<\/code>, since the customer IP header is an IPv4 header.<\/p>\n

                  \"IPv6
                  \nFigure 10: IPv6 customer traffic encapsulation using IP-in-IPv6. The provider IPv6 Next Header field is set to 41 because the inner customer header is IPv6.<\/em><\/p>\n

                  The IPv6 customer traffic flow is the same, but the inner header is an IPv6 customer header. The Next Header<\/code> field in the provider IPv6 header must be set to 41<\/code>, since the customer IP header is an IPv6 header.<\/p>\n

                  Transit P routers require only native IPv6 multicast and PIMv6 support; they forward native IPv6 multicast packets without awareness of the overlay. Only edge PEs require multicast VPN functionality, minimizing the deployment footprint.<\/p>\n

                  Why two protocols?<\/strong> BGP coordinates between PEs, determining who participates with Type 1 routes and who wants what traffic with Type 7 routes. PIM builds the multicast forwarding path through the core routers. Core routers run PIM but never touch BGP MVPN. PEs run both, but for different purposes.<\/p>\n

                  Sample Configuration<\/h2>\n

                  The following configuration and verification sections use this reference topology.<\/p>\n

                  \"Reference
                  \nFigure 11: Multicast services over SRv6 \/ IPv6 cores reference topology. Root is the ingress PE, Mid is a bud-node PE, Tail is the egress PE, P1\/P2 are transit routers, and RR is the route reflector.<\/em><\/p>\n

                  Root is the ingress\/source PE, Mid is a bud-node PE, Tail is an egress\/receiver PE, P1\/P2 are transit routers, and RR is the route reflector. Attached hosts represent validation traffic endpoints.<\/p>\n\n\n\n\n\n\n\n\n\n\n
                  Node<\/th>\nRole<\/th>\nLoopback0 IPv6<\/th>\nLoopback0 IPv4<\/th>\n<\/tr>\n<\/thead>\n
                  Root<\/td>\nIngress\/source PE<\/td>\n2001:db8:100::1\/128<\/code><\/td>\n192.0.2.1\/32<\/code><\/td>\n<\/tr>\n
                  P1<\/td>\nTransit P router<\/td>\n2001:db8:100::2\/128<\/code><\/td>\n192.0.2.2\/32<\/code><\/td>\n<\/tr>\n
                  Mid<\/td>\nBud-node PE<\/td>\n2001:db8:100::3\/128<\/code><\/td>\n192.0.2.3\/32<\/code><\/td>\n<\/tr>\n
                  P2<\/td>\nTransit P router<\/td>\n2001:db8:100::4\/128<\/code><\/td>\n192.0.2.4\/32<\/code><\/td>\n<\/tr>\n
                  Tail<\/td>\nReceiver\/egress PE<\/td>\n2001:db8:100::5\/128<\/code><\/td>\n192.0.2.5\/32<\/code><\/td>\n<\/tr>\n
                  RR<\/td>\nRoute Reflector<\/td>\n2001:db8:100::6\/128<\/code><\/td>\n192.0.2.6\/32<\/code><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                  These snippets cover the multicast-specific components and the BGP address families relevant to the example. IPv6 unicast reachability through the provider core, including IS-IS, SRv6 locators, and Loopback0 reachability, is assumed to be already operational. The SRv6 lines provide the L3VPN service context; the multicast tree remains native IPv6 multicast.<\/p>\n

                  The packet-level validation in this article focuses on an IPv4 customer multicast flow carried over an IPv6 Default MDT:<\/p>\n

                    \n
                  • Customer source: 198.51.100.100<\/code><\/li>\n
                  • Customer group: 232.1.1.1<\/code><\/li>\n
                  • VRF: red<\/code><\/li>\n
                  • Default MDT group: ff3e::8000:1<\/code><\/li>\n<\/ul>\n

                    Root Ingress PE<\/h3>\n

                    Root uses 2001:db8:100::1<\/code>, AS 65000<\/code>, and VRF red<\/code>.<\/p>\n

                    router bgp 65000\n<\/span> mvpn\n<\/span> bgp router-id 192.0.2.1\n<\/span> address-family ipv4 unicast\n<\/span>!\n<\/span> address-family vpnv4 unicast\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span>!\n<\/span> address-family vpnv6 unicast\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span>!\n<\/span> neighbor 2001:db8:100::6\n<\/span> remote-as 65000\n<\/span> update-source Loopback0\n<\/span> address-family vpnv4 unicast\n<\/span>!\n<\/span> address-family vpnv6 unicast\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span>!\n<\/span>!\n<\/span> vrf red\n<\/span> rd auto\n<\/span> address-family ipv4 unicast\n<\/span> segment-routing srv6\n<\/span> locator MAIN\n<\/span> alloc mode per-vrf\n<\/span>!\n<\/span> redistribute connected\n<\/span> redistribute static\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span> segment-routing srv6\n<\/span> locator MAIN\n<\/span> alloc mode per-vrf\n<\/span>!\n<\/span> redistribute connected\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span>!\n<\/span>!\n<\/span>router static\n<\/span> vrf red\n<\/span> address-family ipv4 unicast\n<\/span> 198.51.100.100\/32 198.51.100.1\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span>route-policy rpf-for-srv6-mcast\n<\/span> set core-tree pim-default-v6\n<\/span>end-policy\n<\/span>multicast-routing\n<\/span> address-family ipv6\n<\/span> interface all enable\n<\/span>!\n<\/span> vrf red\n<\/span> address-family ipv4\n<\/span> mdt source ipv6 Loopback0\n<\/span> interface all enable\n<\/span> bgp auto-discovery pim6\n<\/span>!\n<\/span> mdt default ipv6 ff3e::8000:1\n<\/span>!\n<\/span> address-family ipv6\n<\/span> mdt source ipv6 Loopback0\n<\/span> interface all enable\n<\/span> bgp auto-discovery pim6\n<\/span>!\n<\/span> mdt default ipv6 ff3e::8000:1\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span>router pim\n<\/span> address-family ipv6\n<\/span> interface Loopback0\n<\/span> enable\n<\/span>!\n<\/span> interface HundredGigE0\/0\/0\/0\n<\/span> enable\n<\/span>!\n<\/span>!\n<\/span> vrf red\n<\/span> address-family ipv4\n<\/span> rpf topology route-policy rpf-for-srv6-mcast\n<\/span> mdt c-multicast-routing bgp\n<\/span>!\n<\/span> interface HundredGigE0\/0\/0\/2\n<\/span> enable\n<\/span>!\n<\/span>!\n<\/span> address-family ipv6\n<\/span> rpf topology route-policy rpf-for-srv6-mcast\n<\/span> mdt c-multicast-routing bgp\n<\/span>!\n<\/span> interface HundredGigE0\/0\/0\/2\n<\/span> enable\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
                    The same PE structure applies to Mid, 2001:db8:100::3<\/code>, and Tail, 2001:db8:100::5<\/code>; only the loopback addresses, SRv6 locator, BGP router ID, and CE-facing interface differ. In the validation lab, Root redistributes a static route for the IPv4 customer source so receiver PEs have unicast\/RPF reachability for 198.51.100.100\/32<\/code>.<\/p>\n
                    Configuration notes:<\/p>\n
                      \n
                    • mdt default ipv6 ff3e::8000:1<\/code> – The IPv6 SSM group for the Default MDT; each VRF gets a unique group.<\/li>\n
                    • mdt source ipv6 Loopback0<\/code> – The PE loopback used as PIM tree source. It must be reachable through the IPv6 underlay.<\/li>\n
                    • bgp auto-discovery pim6<\/code> – Enables BGP MVPN auto-discovery with a PIMv6-SSM provider tunnel.<\/li>\n
                    • rpf topology route-policy rpf-for-srv6-mcast<\/code> – Directs RPF to use the PIMv6-SSM core tree.<\/li>\n
                    • mdt c-multicast-routing bgp<\/code> – Generates MVPN Type 7 routes instead of PIM over MDT for C-multicast state.<\/li>\n
                    • PIM is enabled on Loopback0 and all core-facing interfaces, which builds the PIMv6-SSM underlay trees.<\/li>\n
                    • address-family ipv4 mvpn<\/code> and address-family ipv6 mvpn<\/code> are the MVPN address families used in this IOS XR validation. Do not replace them with vpnv4 multicast<\/code> or vpnv6 multicast<\/code>.<\/li>\n<\/ul>\n
                      Route Reflector<\/h3>\n
                      The RR uses 2001:db8:100::6<\/code> and AS 65000<\/code>.<\/p>\n
                      router bgp 65000\n<\/span> mvpn\n<\/span> bgp router-id 192.0.2.6\n<\/span> address-family ipv4 unicast\n<\/span>!\n<\/span> address-family vpnv4 unicast\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span>!\n<\/span> address-family vpnv6 unicast\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span>!\n<\/span>! Root (PE1)\n<\/span> neighbor 2001:db8:100::1\n<\/span> remote-as 65000\n<\/span> update-source Loopback0\n<\/span> address-family ipv4 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family vpnv4 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family vpnv6 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span> route-reflector-client\n<\/span>!\n<\/span>!\n<\/span>! Mid (PE2)\n<\/span> neighbor 2001:db8:100::3\n<\/span> remote-as 65000\n<\/span> update-source Loopback0\n<\/span> address-family ipv4 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family vpnv4 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family vpnv6 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span> route-reflector-client\n<\/span>!\n<\/span>!\n<\/span>! Tail (PE3)\n<\/span> neighbor 2001:db8:100::5\n<\/span> remote-as 65000\n<\/span> update-source Loopback0\n<\/span> address-family ipv4 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family vpnv4 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv6 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family vpnv6 unicast\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv4 mvpn\n<\/span> route-reflector-client\n<\/span>!\n<\/span> address-family ipv6 mvpn\n<\/span> route-reflector-client\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
                      The RR does not need VRF configuration; it only reflects BGP MVPN routes. All three PEs, Root, Mid, and Tail, are route-reflector-client<\/code> under ipv4 mvpn<\/code> and ipv6 mvpn<\/code>. VPN unicast address families are still needed for customer route reachability.<\/p>\n
                      Transit Routers<\/h3>\n
                      P1 uses 2001:db8:100::2<\/code>; P2 uses 2001:db8:100::4<\/code>.<\/p>\n
                      multicast-routing\n<\/span> address-family ipv6\n<\/span> interface all enable\n<\/span>!\n<\/span>!\n<\/span>router pim\n<\/span> address-family ipv6\n<\/span> interface HundredGigE0\/0\/0\/0\n<\/span> enable\n<\/span>!\n<\/span> interface HundredGigE0\/0\/0\/1\n<\/span> enable\n<\/span>!\n<\/span> interface HundredGigE0\/0\/0\/2\n<\/span> enable\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
                      P routers need only global IPv6 multicast routing and PIMv6 on core-facing interfaces, with no BGP MVPN, no VRF, and no multicast-routing VRF configuration. They forward native IPv6 multicast and propagate PIMv6-SSM joins hop-by-hop with zero awareness of customer VPN state.<\/p>\n
                      PIM is enabled only on the required core-facing interfaces. This avoids activating PIM on unintended links; interface all enable<\/code> under multicast-routing<\/code> is retained only as a lab convenience.<\/p>\n
                      Verification<\/h2>\n
                      The following verification steps walk through the multicast state layer by layer, matching the order in which the control plane builds up: first BGP MVPN auto-discovery, then provider PIM trees, then customer multicast joins, and finally data-plane forwarding. Run the commands on the indicated routers using the reference topology.<\/p>\n
                      Step 1: BGP MVPN Auto-Discovery<\/h3>\n
                      After enabling bgp auto-discovery pim6<\/code> on all PEs, each PE originates a Type 1, Intra-AS I-PMSI A-D, route carrying a PMSI Tunnel Attribute that tells remote PEs how to join its Default MDT.<\/p>\n
                      ! === Root - verify Type 1 exchange ===\n<\/span>show bgp ipv4 mvpn route-type 1\n<\/span>! Expected: Three Type 1 routes - one local, two received via RR:\n<\/span>! *> [1][2001:db8:100::1]\/136\n<\/span>! *>i[1][2001:db8:100::3]\/136\n<\/span>! *>i[1][2001:db8:100::5]\/136\n<\/span>! The \"i\" prefix means iBGP-learned; absence means locally originated.\n<\/span>! === RR - verify it reflects all three Type 1 routes ===\n<\/span>show bgp ipv4 mvpn route-type 1\n<\/span>! Expected: All three PE Type 1 routes, each with the originator's loopback as next-hop:\n<\/span>! *>i[1][2001:db8:100::1]\/136\n<\/span>! *>i[1][2001:db8:100::3]\/136\n<\/span>! *>i[1][2001:db8:100::5]\/136\n<\/span><\/code><\/pre>\n
                      Optionally inspect the PMSI Tunnel Attribute inside a Type 1 route to confirm the underlay tree parameters.<\/p>\n
                      ! === Tail - inspect Root's Type 1 detail ===\n<\/span>show bgp ipv4 mvpn [1][2001:db8:100::1]\/136 detail\n<\/span>! Key fields to verify in the output:\n<\/span>! PMSI: flags 0x00, type 3 (PIM SSM), label 0\n<\/span>! Originating PE: 2001:db8:100::1\n<\/span>! Multicast Group: ff3e::8000:1\n<\/span>!\n<\/span>! This tells Tail: \"To receive Root's MDT traffic, join the PIMv6-SSM tree\n<\/span>! (2001:db8:100::1, ff3e::8000:1).\"\n<\/span>! PMSI tunnel type 3 = PIM-SSM. This is separate from BGP MVPN route type 3,\n<\/span>! which is S-PMSI A-D \/ Data MDT signaling.\n<\/span><\/code><\/pre>\n
                      Step 2: Provider PIM Trees<\/h3>\n
                      Triggered by the PMSI information in Type 1 routes, each PE initiates PIMv6-SSM joins toward the other PEs’ loopbacks for group ff3e::8000:1<\/code>. Transit routers P1 and P2 forward these joins hop-by-hop with no BGP awareness needed.<\/p>\n
                      ! === Root - verify provider PIM trees ===\n<\/span>show pim ipv6 topology ff3e::8000:1\n<\/span>! Expected: P(S,G) entries for the Default MDT group ff3e::8000:1:\n<\/span>!\n<\/span>! (2001:db8:100::1, ff3e::8000:1) SPT - Root's own tree\n<\/span>! RPF: Loopback0,2001:db8:100::1*\n<\/span>! Loopback0 fwd LI LH\n<\/span>! HundredGigE0\/0\/0\/0 fwd Join\n<\/span>!\n<\/span>! (2001:db8:100::5, ff3e::8000:1) SPT - Tail's tree\n<\/span>! RPF: HundredGigE0\/0\/0\/0,fe80::...\n<\/span>! Loopback0 fwd LH MVS MV6S\n<\/span>!\n<\/span>! \"MV6S\" flag = IPv6 multicast VPN source - indicates this tree feeds the MDT.\n<\/span>! \"LI\" = local interest, \"LH\" = last hop.\n<\/span>! === P2 (transit router) - verify hop-by-hop PIM state ===\n<\/span>show pim ipv6 topology ff3e::8000:1\n<\/span>! Expected: P2 is pure transit - no VRF and no MVPN state:\n<\/span>!\n<\/span>! (2001:db8:100::1, ff3e::8000:1) SPT\n<\/span>! RPF: toward Root's direction (HundredGigE0\/0\/0\/0 toward Mid\/P1)\n<\/span>! Outgoing: toward Tail (HundredGigE0\/0\/0\/1)\n<\/span>!\n<\/span>! (2001:db8:100::5, ff3e::8000:1) SPT\n<\/span>! RPF: toward Tail's direction (HundredGigE0\/0\/0\/1)\n<\/span>! Outgoing: toward Root\/Mid (HundredGigE0\/0\/0\/0)\n<\/span>!\n<\/span>! P2 forwards native IPv6 multicast only.\n<\/span>! === Tail - verify provider PIM trees ===\n<\/span>show pim ipv6 topology ff3e::8000:1\n<\/span>! Expected: Mirror image of Root:\n<\/span>!\n<\/span>! (2001:db8:100::1, ff3e::8000:1) SPT - Root's tree (Tail joined it)\n<\/span>! RPF: toward P2 (incoming from core)\n<\/span>! Loopback0 fwd LH MV6S\n<\/span>!\n<\/span>! (2001:db8:100::5, ff3e::8000:1) SPT - Tail's own tree\n<\/span>! RPF: Loopback0,2001:db8:100::5*\n<\/span>! Loopback0 fwd LI LH\n<\/span>! HundredGigE0\/0\/0\/0 fwd Join\n<\/span><\/code><\/pre>\n
                      Step 3: Customer Multicast Join<\/h3>\n
                      When a receiver sends an IGMP or PIM join for a customer (S,G)<\/code>, the receiver PE creates VRF C(S,G)<\/code> state and originates a BGP MVPN Type 7 Source Tree Join route. The ingress PE, Root, receives the Type 7 via the RR and starts forwarding customer traffic onto the MDT.<\/p>\n
                      ! === Tail - verify VRF customer multicast state after receiver joins ===\n<\/span>show pim vrf red topo 232.1.1.1 198.51.100.100\n<\/span>! Expected for customer flow (198.51.100.100, 232.1.1.1):\n<\/span>!\n<\/span>! (198.51.100.100,232.1.1.1) SPT\n<\/span>! JP: Join(BGP) RPF: mdt6red,2001:db8:100::1\n<\/span>! HundredGigE0\/0\/0\/1 fwd Join(...) LI\n<\/span>!\n<\/span>! KEY INDICATORS:\n<\/span>! \"Join(BGP)\" - the join was signaled via BGP Type 7, NOT PIM over the MDT.\n<\/span>! \"RPF: mdt6red,2001:db8:100::1\" - RPF points to Root via the MDT tunnel interface.\n<\/span>! The outgoing interface is toward the CE\/receiver.\n<\/span>! === Tail - verify Type 7 route originated locally ===\n<\/span>show bgp ipv4 mvpn route-type 7\n<\/span>! Expected: locally originated Type 7 encoding the customer C-source and C-group:\n<\/span>! *> [7][192.0.2.1:0][65000][32][198.51.100.100][32][232.1.1.1]\/184\n<\/span>! 0.0.0.0 0 i\n<\/span>!\n<\/span>! Route encoding: [Type][RD][Source-AS][SrcLen][C-Source][GrpLen][C-Group]\n<\/span>! Next-hop 0.0.0.0 = locally originated.\n<\/span>! === Root - verify VRF customer multicast state after receiving Type 7 ===\n<\/span>show pim vrf red topo 232.1.1.1 198.51.100.100\n<\/span>! Expected:\n<\/span>! (198.51.100.100,232.1.1.1) SPT\n<\/span>! JP: Join(...) RPF: HundredGigE0\/0\/0\/2,198.51.100.1\n<\/span>! mdt6red fwd BGP\n<\/span>!\n<\/span>! KEY INDICATORS:\n<\/span>! \"Join(now)\" - Root has an active join for this C(S,G).\n<\/span>! \"RPF: HundredGigE0\/0\/0\/2,198.51.100.1\" - RPF toward the CE\/source.\n<\/span>! \"mdt6red fwd BGP\" - outgoing onto the MDT tunnel, triggered by BGP Type 7.\n<\/span>! === Root - verify Type 7 received from a receiver PE via RR ===\n<\/span>show bgp ipv4 mvpn route-type 7\n<\/span>! Expected: Type 7 received from a receiver PE via RR:\n<\/span>! *>i[7][192.0.2.1:0][65000][32][198.51.100.100][32][232.1.1.1]\/184\n<\/span>! 2001:db8:100::3 100 0 i\n<\/span>!\n<\/span>! If both Mid and Tail have active receivers, the RR can learn one Type 7 route\n<\/span>! per receiver PE. The ingress PE installs the selected path or paths according\n<\/span>! to normal BGP best-path and multipath behavior.\n<\/span><\/code><\/pre>\n
                      Step 4: IPv4 Customer Data Plane<\/h3>\n
                      Once the control plane is fully converged, verify that the IPv4 customer multicast traffic is flowing end-to-end over the IPv6 MDT.<\/p>\n
                      In the validation setup, traffic generator and receiver hosts were attached to the PE customer-facing interfaces to prove packet delivery for the IPv4 SSM flow. A traffic source host generated UDP multicast traffic from 198.51.100.100<\/code> toward 232.1.1.1<\/code>. Receiver hosts behind Mid and Tail joined the group and each received the full packet stream. The attached validation hosts are used only to generate and receive customer multicast traffic; they are not part of the provider multicast service architecture.<\/p>\n
                      ! === Root - confirm customer traffic is encapsulated onto the MDT ===\n<\/span>show mrib vrf red route 232.1.1.1 198.51.100.100\n<\/span>! Expected: forwarding entry for the customer (S,G) with:\n<\/span>! Incoming interface: HundredGigE0\/0\/0\/2\n<\/span>! Outgoing interface: mdt6red\n<\/span>! === Tail - confirm customer traffic is decapsulated from the MDT ===\n<\/span>show mrib vrf red route 232.1.1.1 198.51.100.100\n<\/span>! Expected: forwarding entry for the customer (S,G) with:\n<\/span>! Incoming interface: mdt6red\n<\/span>! Outgoing interface: HundredGigE0\/0\/0\/1\n<\/span>! === Provider core - confirm native IPv6 MDT state ===\n<\/span>show mrib ipv6 route ff3e::8000:1\n<\/span>! Expected: provider P(S,G) entries for the PE loopbacks and MDT group.\n<\/span>! On transit P routers, the entries should contain only core-facing physical interfaces,\n<\/span>! with no VRF, no BGP MVPN, and no MDT tunnel interface.\n<\/span><\/code><\/pre>\n
                      Representative validation lab output from the IPv4 packet test:<\/p>\n
                      TrafficSource:\n<\/span> 1000 packets sent from 198.51.100.100 to 232.1.1.1 UDP\/5000\n<\/span>MidReceiver:\n<\/span> 1000 packets received\n<\/span> rx1000 from 198.51.100.100... srv6-mcast seq=1000\n<\/span>TailReceiver:\n<\/span> 1000 packets received\n<\/span> rx1000 from 198.51.100.100... srv6-mcast seq=1000\n<\/span><\/code><\/pre>\n
                      Representative PE state while traffic was active:<\/p>\n
                      Root:\n<\/span> (198.51.100.100,232.1.1.1) SPT\n<\/span> RPF: HundredGigE0\/0\/0\/2,198.51.100.1\n<\/span> mdt6red fwd BGP\n<\/span> Incoming Interface List\n<\/span> HundredGigE0\/0\/0\/2\n<\/span> Outgoing Interface List\n<\/span> mdt6red\n<\/span>Mid:\n<\/span> (198.51.100.100,232.1.1.1) SPT\n<\/span> JP: Join(BGP) RPF: mdt6red,2001:db8:100::1\n<\/span> Incoming Interface List\n<\/span> mdt6red\n<\/span> Outgoing Interface List\n<\/span> HundredGigE0\/0\/0\/2\n<\/span>Tail:\n<\/span> (198.51.100.100,232.1.1.1) SPT\n<\/span> JP: Join(BGP) RPF: mdt6red,2001:db8:100::1\n<\/span> Incoming Interface List\n<\/span> mdt6red\n<\/span> Outgoing Interface List\n<\/span> HundredGigE0\/0\/0\/1\n<\/span><\/code><\/pre>\n
                      Step 5: IPv6 Customer Data Plane<\/h3>\n
                      The same VRF and Default MDT model also carries IPv6 customer multicast traffic. In the validation setup, the IPv6 customer source is 2001:db8:198:51::100<\/code>, the IPv6 customer SSM group is ff3e::8000:2321<\/code>, and the traffic is carried in VRF red<\/code> over the same IPv6 Default MDT group ff3e::8000:1<\/code>.<\/p>\n
                      Mid and Tail use static MLD receiver state for the IPv6 customer SSM flow:<\/p>\n
                      router mld\n<\/span> vrf red\n<\/span> interface HundredGigE0\/0\/0\/2\n<\/span> static-group ff3e::8000:2321 2001:db8:198:51::100\n<\/span>!\n<\/span>!\n<\/span>!\n<\/span><\/code><\/pre>\n
                      On Tail, the receiver-facing interface is HundredGigE0\/0\/0\/1<\/code>; the static group statement is otherwise the same. This creates customer VRF receiver interest for the IPv6 C(S,G)<\/code>, just as IGMP or PIM receiver interest creates customer VRF state for the IPv4 C(S,G)<\/code>.<\/p>\n
                      ! === Root - confirm IPv6 customer traffic is encapsulated onto the MDT ===\n<\/span>show pim vrf red ipv6 topology\n<\/span>show mrib vrf red ipv6 route\n<\/span>! Expected: forwarding entry for the IPv6 customer C(S,G) with:\n<\/span>! C-source: 2001:db8:198:51::100\n<\/span>! C-group: ff3e::8000:2321\n<\/span>! Incoming interface: HundredGigE0\/0\/0\/2\n<\/span>! Outgoing interface: mdt6red\n<\/span>! === Mid - confirm IPv6 customer traffic is decapsulated from the MDT ===\n<\/span>show pim vrf red ipv6 topology\n<\/span>show mrib vrf red ipv6 route\n<\/span>! Expected: forwarding entry for the IPv6 customer C(S,G) with:\n<\/span>! Incoming interface: mdt6red\n<\/span>! Outgoing interface: HundredGigE0\/0\/0\/2\n<\/span>! === Tail - confirm IPv6 customer traffic is decapsulated from the MDT ===\n<\/span>show pim vrf red ipv6 topology\n<\/span>show mrib vrf red ipv6 route\n<\/span>! Expected: forwarding entry for the IPv6 customer C(S,G) with:\n<\/span>! Incoming interface: mdt6red\n<\/span>! Outgoing interface: HundredGigE0\/0\/0\/1\n<\/span><\/code><\/pre>\n
                      Representative validation lab output from the IPv6 packet test:<\/p>\n
                      TrafficSource:\n<\/span> 1000 packets sent from 2001:db8:198:51::100 to ff3e::8000:2321 UDP\/5001\n<\/span>MidReceiver:\n<\/span> 1000 packets received\n<\/span> rx1000 from 2001:db8:198:51::100... srv6-mcast6 seq=1000\n<\/span>TailReceiver:\n<\/span> 1000 packets received\n<\/span> rx1000 from 2001:db8:198:51::100... srv6-mcast6 seq=1000\n<\/span><\/code><\/pre>\n
                      Representative IPv6 customer VRF state while traffic was active:<\/p>\n
                      Root:\n<\/span> (2001:db8:198:51::100,ff3e::8000:2321) SPT\n<\/span> RPF: HundredGigE0\/0\/0\/2,2001:db8:198:51::1\n<\/span> mdt6red fwd BGP\n<\/span> Incoming Interface List\n<\/span> HundredGigE0\/0\/0\/2\n<\/span> Outgoing Interface List\n<\/span> mdt6red\n<\/span>Mid:\n<\/span> (2001:db8:198:51::100,ff3e::8000:2321) SPT\n<\/span> JP: Join(BGP) RPF: mdt6red,2001:db8:100::1\n<\/span> Incoming Interface List\n<\/span> mdt6red\n<\/span> Outgoing Interface List\n<\/span> HundredGigE0\/0\/0\/2\n<\/span>Tail:\n<\/span> (2001:db8:198:51::100,ff3e::8000:2321) SPT\n<\/span> JP: Join(BGP) RPF: mdt6red,2001:db8:100::1\n<\/span> Incoming Interface List\n<\/span> mdt6red\n<\/span> Outgoing Interface List\n<\/span> HundredGigE0\/0\/0\/1\n<\/span><\/code><\/pre>\n
                      Deployment Considerations<\/h2>\n
                      For each multicast-enabled VRF, the initial deployment model uses MDT transport over IPv6 only. Operators transitioning from an IPv4 multicast core should plan for a dedicated migration window rather than a mixed-mode cutover.<\/p>\n
                      Key design considerations:<\/p>\n