10. GTM
10.1. GTM Overview
GTM with BGP Multicast VPN (BGP-MVPN), as specified in RFC 7716, allows a Service Provider (SP) to use the same multicast architecture that was originally developed for VPNs to distribute multicast routing information that is not specific to VPNs. Instead of storing the routing information in VRFs, multicast routing information is maintained in a global table for the router.
The architecture can be logically divided into a core network and non-core (attachment) networks.The multicast routing protocol used in the core network may not be the same as the protocol used in the attachment networks. As there is a protocol boundary between the core and attachment networks, the term Protocol Boundary Router (PBR) refers to the core routers that are at the boundary. A PBR is not necessarily an edge router in the PE sense; however, a PBR in the SP network marks the border of any tunnels that are used to transport multicast traffic across the core network. Routers that are attached to the PBRs but that are not part of the core network are referred to as Attachment Routers (ARs).
Figure 10: GTM Network Topology Example
Multicast data traffic from an AR is tunneled through the core network from an ingress PBR to one or more egress PBRs, using multicast routing information stored in the PBR’s global table. The global table learns the PBR’s multicast routing information from the ARs attached to the PBR, and distributes the information among the PBRs using BGP. PBRs use the same BGP-MVPN procedures used by PE routers to route multicast VPN traffic, with some adaptations to the procedures to use the global table instead of a VRF.
By using the BGP procedures designed for MVPN to support GTM, a single control plane is available to govern the use of both VPN and non-VPN multicast. The features and characteristics of MVPN carry over automatically to GTM, including, but not limited to:
- scaling
- aggregation
- transport over RSVP tunnels in the SP network
- support for non-segmented intra-autonomous systems (ASs) tunnels
- support for PIM-SSM outside of the core
- support for both IPv4 and IPv6 multicast flows over an IPv4 SP infrastructure
- support for unsolicited flooded data (including support for BSR as an RP-to-group mapping protocol
10.1.1. Using BGP-MVPN Procedures in GTM
10.1.1.1. Route Distinguishers and Route Targets
The BGP routes used in the MVPN procedures have a Subsequent Address Family Identifier (SAFI) value of 5, or MCAST-VPN. The Network Layer Reachability Information (NLRI) format for MCAST-VPN routes consists of a Route Type (RT) field and depending on the RT, a Route Distinguisher (RD) Extended Community (EC) field.
 | Note: The ECs are automatically configured for GTM and are not visible in the configuration. |
To distinguish MCAST-VPN routes originated for VPNs from MCAST-VPN routes in support of GTM, the RD field, if defined within that route’s NLRI, must be set to zero (that is, 64 bits of zero). An RD of all zeros associates that route with GTM, as no VRF can have an RD of zero.
MVPN procedures use two types of RTs, one of which is carried only in the routes of C-multicast shared tree joins, C-multicast source tree joins, and leaf auto-discovery routes (A-D routes). This RT type identifies the PE router that has been selected by the route’s originator as the Upstream PE or as the Upstream Multicast Hop (UMH) for a particular multicast flow or set of multicast flows. This RT must be an IPv4- or IPv6-address-specific EC, where the Global Administrator field identifies the Upstream PE or the UMH. If the Global Administrator field identifies the Upstream PE, the Local Administrator field identifies a particular VRF in that PE.
To support GTM, this type of RT is used in the same situations as in the MVPN specifications, with the modification that the Local Administrator field of this RT type must always be set to zero. This implicitly identifies the global table rather than identifying a VRF. This type of RT is referred to as an upstream-node-identifying RT.
10.1.1.2. UMH-Eligible Routes
For MVPN, routes of SAFI 128 or 129 are UMH-eligible routes. For GTM, routes of SAFI 1, SAFI 4, or SAFI 2 are UMH-eligible routes. Imported routes of SAFI 2 in the global table are UMH-eligible routes; otherwise, routes of SAFI 1 or SAFI 4 are considered UMH-eligible routes. For UMH determination, SAFI 1 and SAFI 4 routes containing the same IP prefix in their respective NLRI fields are considered by the BGP best-path selection process to be comparable.
UMH-eligible routes that have a SAFI of 1, 2, or 4 carry both the VRF Route Import EC and the Source AS EC. These ECs are automatically configured for GTM.
10.1.1.3. BGP Route Types Supported
Table 35: BGP Route Types
BGP Route Type | Name | Description | Supported for GTM |
1 | Intra-AS I-PMSI AD route | Originated by all PBR routers. Used for advertising and learning intra-AS MVPN membership information. | Yes, always originated by SR OS |
2 | Inter-AS I-PMSI A-D route | Originated by ASBR routers. Used for advertising and learning inter-AS MVPN membership information. | No (no Inter-AS support) |
3 | S-PMSI A-D route | Originated by sender PBRs. Used for initiating a selective P-tunnel for a particular (C-S, C-G). | Yes |
4 | Leaf A-D route | Originated by receiver PBRs in response to receiving a Type 3 route. Used by sender PBR to discover the leaves of a selective P-tunnel. | Yes |
5 | Source Active A-D route | Originated by the PBR that discovers an active VPN multicast source. Used by PBRs to learn the identity of active VPN multicast sources. | Yes |
6 | Shared Tree Join route | Originated by receiver PBRs. Originated when a PE receives a shared tree C-join (C-*, C-G) through its PE-CE interface. | Yes |
7 | Source Tree Join route | Originated by receiver PBRs. Originated when a PBR receives a source tree C-join (C-S, C-G) or originated by the PBR that already has a Type 6 route and receives a Type 5 route. | Yes, for non-segmented trees. |
10.2. Configuring GTM
10.2.1. Configuration Recommendations
When configuring GTM, the following recommendations should be considered.
- In a dual-homing configuration, ECMP to the upstream multicast hop (UMH) routers must be configured for the BGP routes to be used. If the UMH routers are unreachable via ECMP, it may cause duplicate traffic in the core. This behavior is consistent with RFC 7716, section 2.3.4., which states that the single forwarder selection (SFS) procedure cannot be applied to GTM.
- For IPv6 GTM, the IPv4 address must be configured as the IPv6 system address, as in the following example.*A:Dut-F>config>router#interface "system"address 10.20.1.4/32ipv6address ::a14:104/128exitno shutdownexit
| Note: GTM auto-discovery (config>router>pim>gtm>auto-discovery) cannot be configured when MoFRR (multicast-fast-failover or multicast6-fast-failover) is enabled. |
10.2.2. Configuring GTM with CLI
Consider the following example configuration:
Figure 11: Example Configuration
where
- routers A and F are CE routers
- routers B, C, D, and E are MSR routers in the core network
- the multicast source is at x4
- the multicast receivers are at x1, x2, and x3
Perform the following steps to configure GTM:
- Configure PIM parameters for GTM.The following output displays the PIM configuration.*B:Dut-D>config>router>pim# info----------------------------------------------interface "intf_to_B"shutdownexitinterface "intf_to_E"shutdownexitapply-to allrpstaticaddress 110.100.1.1group-prefix 224.0.0.0/4exitexitbsr-candidateshutdownexitrp-candidateshutdownexitexitgtmauto-discovery defaultexitno mc-ecmp-balanceno shutdown----------------------------------------------*B:Dut-D>config>router>pim#
- Configure the GTM parameters.The following output displays the GTM configuration.*B:Dut-D>config>router>gtm# info----------------------------------------------mvpnprovider-tunnelinclusiversvplsp-template "IpmsiTmpl"no shutdownexitexitselectiversvplsp-template "SpmsiTmpl"no shutdownexitmaximum-p2mp-spmsi 4000data-threshold 224.0.0.0/4 1exitexit----------------------------------------------*B:Dut-D>config>router>gtm#
- Configure a route policy for BGP.The following output displays the route policy configuration.*B:Dut-D>config>router>policy-options# info----------------------------------------------prefix-list "sourceList"prefix 10.10.0.0/16 longerprefix 100.100.0.0/16 longerprefix 100.114.0.0/16 longerprefix 3ffe::10:10:0:0/96 longerprefix 3ffe::100:100:0:0/96 longerprefix 3ffe::100:114:0:0/96 longerexitpolicy-statement "acceptAll"default-action acceptexitexitpolicy-statement "acceptAllBgp"entry 10fromprotocol ripexitaction acceptexitexitentry 11fromprotocol ripngexitaction acceptexitexitdefault-action dropexitexitpolicy-statement "acceptAllPref8"default-action acceptpreference 8exitexit----------------------------------------------*B:Dut-D>config>router>policy-options#
- Configure BGP parameters for GTM.The following output displays the BGP configuration on router D.*B:Dut-D#configure router bgp*B:Dut-D>config>router>bgp# info----------------------------------------------connect-retry 1multipath 16export "acceptAllBgp"router-id 10.20.1.4rapid-withdrawalrapid-update mvpn-ipv4 mdt-safi mvpn-ipv6mvpn-vrf-import-subtype-newbest-path-selectionignore-nh-metricexitgroup "none"family ipv4 ipv6 mvpn-ipv4 mvpn-ipv6 label-ipv4 label-ipv6next-hop-selflocal-address 10.20.1.4neighbor 10.20.1.2peer-as 200exitneighbor 10.20.1.3med-out 100peer-as 200exitneighbor 10.20.1.5med-out 100peer-as 200exitexitno shutdown----------------------------------------------
The following output displays the MVPN context on router D.
The following output displays the PIM source group database information on router D.
The following output displays the PMSI information on router D.