Configuring Multiprotocol BGP-Based Multicast VPNs: Next-Generation

To implement multiprotocol BGP-based multicast VPNs, configure the following:

• Creating a Unique Logical Loopback Interface for the Routing Instance
• Configuring Interfaces for Layer 3 VPNs
• Configuring BGP, MPLS, RSVP, and an IGP on the PE and Core Routers
• Creating a Routing Instance for Multiprotocol BGP-Based Multicast VPN
• Option: Configuring Sender and Receiver Sites
• Option: Specifying Route Targets
• Configuring Provider Tunnels
• Enabling Multicast VPN in BGP
• Configuring Traffic Engineering Point-to-Multipoint LSPs in Provider Tunnels
• Configuring the Master PIM Instance on the PE Router
• Configuring the Router’s IPv4 Bootstrap Router Priority

Creating a Unique Logical Loopback Interface for the Routing Instance

To facilitate the PIM protocol within a Layer 3 VPN, configure a unique loopback interface for the routing instance at the [edit interfaces lo0 unit] hierarchy level:

Configuring Interfaces for Layer 3 VPNs

Configure the Layer 3 VPN logical interfaces and specify the family as inet:

Configuring BGP, MPLS, RSVP, and an IGP on the PE and Core Routers

To send multicast traffic across a Layer 3 VPN, you must configure network protocols to handle intradomain routing (an interior gateway protocol [IGP], such as Open Shortest Path First [OSPF] or Intermediate System-to-Intermediate System [IS-IS]), interdomain routing (Border Gateway Protocol [BGP]), label switching (Multiprotocol Label Switching [MPLS]), and path signaling (Resource Reservation Protocol [RSVP]). For more information about these protocols and examples of how to configure these protocols to support a Layer 3 VPN, see the JUNOS VPNs Configuration Guide.

Note: In multicast Layer 3 VPNs, the multicast PE routers must use the primary loopback address (or router ID) for sessions with their internal BGP peers. If the PE routers use a route reflector with next-hop self-configured, Layer 3 multicast over VPN does not work because PIM cannot transmit upstream interface information for multicast sources behind remote PE routers into the network core. Multicast Layer 3 VPNs require the BGP next-hop address of the VPN route to match the BGP next-hop address of the loopback VRF instance address.

Creating a Routing Instance for Multiprotocol BGP-Based Multicast VPN

By default a multiprotocol BGP-based multicast VPN routing instance attaches to both sender and receiver sites. You can also manually configure the instance to attach to only sender or only receiver sites.

To create a multicast VPN routing instance, include the mvpn statement at the [edit routing-instances routing-instance name protocols] hierarchy level:

Option: Configuring Sender and Receiver Sites

By default, multiprotocol BGP-based VPNs are attached to both sender and receiver sites. To specify that a VPN be attached only to a sender site or only to a receiver site, include the receiver-site or sender-site statement at the [edit routing instances routing-instance-name protocols mvpn] hierarchy level:

Option: Specifying Route Targets

Specifying route targets for sender and receiver sites is useful when there is a mix of sender only, receiver only, and sender and receiver sites. This is because a sender site’s routing table is used for exporting routes from a sender site and importing routes from a receiver site. A receiver site's routing table is used for exporting routes from a receiver site and importing routes from a sender site. A sender and receiver site does both. The route targets configured under multicast VPNs apply only to multicast VPN AD routes of type 1, 2, 3, and 5.

A PE router with sites in a specific multicast VPN must determine whether a received automatic discovery route is from a sender site or receiver site based on the following:

• If the PE router is configured to be only in a sender site, route targets are imported only from receiver sites. Imported automatic discovery routes must be from a receiver site.
• If the PE router is configured to be only in a receiver site, route targets are imported only from sender sites. Imported automatic discovery routes must be from a sender site.
• If the PE router is configured to be both in sender and receiver sites, the following guidelines apply:
  • Along with an import route target, you can optionally configure whether the route target is from a receiver or a sender site.
  • If a configuration is not provided, an imported automatic discovery route is treated as belonging to both the sender site and the receiver site.

For more information on route targets, see the JUNOS VPNs Configuration Guide.

To specify route targets, include the route-target statement at the [edit routing-instances routing-instance-name protocols mvpn] hierarchy level:

Existing vrf-import or vrf-export policies for importing and exporting vpn routes might prevent import or export of multicast VPN routes if the policies reflect routes based on the policy qualifier protocol. The workaround is to relax the policy to not reflect routes based on the protocol type or to use additional multicast-VPN-specific configuration.

If the vrf-import policy does not import bgp routes, multicast VPN routes of type 1, 2, 3, or 5 imported by BGP will be rejected. There are two workarounds:

• You can add a term to allow routes from protocol bgp with family inet-mvpn:

  term 2 {

  from {

  protocol bgp;

  family inet-mvpn;

  community vpn_blue;

  }

  then {

  accept;

  }

  }

  The customer can configure an import target under mvpn. The multicast VPN route of type 1, 2, 3, or 5 matching the configured target will be imported.

  protocol mvpn {

  import-target {

  target target:2:2;

  }

  }

• If the vrf-export policy uses a policy qualifier of type protocol to reject routes, the multicast VPN routes of type 1, 2, 3, or 5 will not be exported. This is because JUNOS does not support a policy qualifier for protocol multicast VPN. The workaround is to configure an export target under multicast VPN without configuring unicast:

  protocol mvpn {

  export-target {

  target target:2:2;

  }

  }

  }

Configuring Provider Tunnels

The source address for a PIM-SM provider tunnel is the loopback address of the loopback interface in inet.0.

To configure a provider tunnel, include the provider-tunnel statement at the [edit routing-instances routing-instance-name] hierarchy level:

Enabling Multicast VPN in BGP

You also must enable multicast VPN by including the inet-mvpn or inet6-mvpn statements at the [edit protocols bgp family] hierarchy level:

Configuring Traffic Engineering Point-to-Multipoint LSPs in Provider Tunnels

You can configure point-to-multipoint MPLS traffic engineering data plane support for intra-AS traffic. Point-to-multipoint LSPs can be used for TE inclusive and selective provider tunnels. A multicast VPN can be configured to use a combination of inclusive and selective trees or only inclusive trees or only selective trees. Aggregation is not supported for point-to-multipoint TE LSPs.

Note: Configure either LDP or regular MPLS LSPs between PE routers to ensure VPN unicast connectivity. Point-to-multipoint LSPs are used for multicast data forwarding only.

You must configure the following when configuring point-to-multipoint LSPs in provider tunnels:

• The BGP multicast VPN control plane, as described in Creating a Routing Instance for Multiprotocol BGP-Based Multicast VPN.
• Point-to-multipoint TE as the provider tunnel technology on each PE configured for multicast VPN that belongs to the sender site.
• Either a VT interface or a vrf-table-label on the multicast VPN instance. For more information about configuring VT interfaces, see the JUNOS VPNs Configuration Guide.
• Point-to-multipoint TE support on each P router.

Intra-AS Inclusive Point-to-Multipoint TE LSPs

Point-to-multipoint TE LSPs are supported as the data plane for intra-AS inclusive provider tunnels. On each PE router, a point-to-multipoint TE LSP must be configured for every multicast VPN instance that belongs to a sender site set. This means that if there are four multicast VPN instances configured on a PE router and three of these multicast VPN instances belong to sender site sets, three point-to-multipoint TE LSPs must be configured on this PE router. The PE would be the root of the three point-to-multipoint TE LSPs, and the leaves of the LSPs would be determined either dynamically or through a static configuration.

If the multicast VPN instance is configured for dynamic leaf discovery, the leaves are automatically discovered through intra-AS autodiscovery routes. The point-to-multipoint LSPs can be signaled using default attributes or configured attributes. If you configure the multicast VPN instance to use default attributes, the LSPs cannot be signaled with bandwidth reservation and do not support CAC. Point-to-multipoint LSPs with configured attributes support both bandwidth reservation and CAC. In addition, they can be configured to support traffic engineering attributes such as fast-reroute.

If the multicast VPN instance is configured for static leaf discovery, you configure the leafs statically. Point-to-multipoint LSPs that are configured statically support all traffic engineering attributes.

To configure dynamic leaf discovery, include the label-switched-path-template statement at the [edit routing-instance routing-instance-name provider-tunnel rsvp-te] hierarchy level. Dynamic discovery can be configured by using default attributes with the default-template statement at the [edit routing-instance routing-instance-name provider-tunnel rsvp-te label-switched-path-template] hierarchy level.

If you want to signal with bandwidth reservation, use CAC, or use other traffic engineering options such as link protection, configure a template for dynamic leaf discovery by including the label-switched-path-template template-name statement at the [edit protocols mpls] hierarchy level:

You can apply the configured or default template by including the template name at the [edit routing-instance routing-instance-name provider-tunnel rsvp-te label-switched-path-template] hierarchy level. Be sure to either configure a vt interface or include the vrf-table-label statement in the routing instance.

To configure static LSPs, include the label-switched-path label-switched-path statement at the [edit protocols mpls] hierarchy level:

To apply statically configured LSPs, include the static statement at the [edit routing-instance routing-instance-name provider-tunnel rsvp-te static-lsp static-lsp-name] hierarchy level:

Intra-AS Selective Provider Tunnels

Point-to-multipoint TE LSPs are supported as the data plane for selective provider tunnels. When selective trees are used, there must be a separate point-to-multipoint TE LSP for each multicast distribution tree in the backbone that carries traffic belonging to a specified set of one or more multicast groups, from one or more multicast VPNs. Multiple groups can be bound to the same selective point-to-multipoint LSP if the selective point-to-multipoint LSP leaves are statically configured. If the leaves are dynamically discovered, only one source or group can be bound to it.

Selective point-to-multipoint LSPs can be statically configured or triggered by a bandwidth threshold. If the threshold rate is configured, a S-PMSI auto-discovery route is generated for a particular (C-S, C-G) if it falls in the range specified by (C-S prefix, C-G prefix) and its data rate exceeds the configured threshold rate.

Below is an example configuration for point-to-multipoint LSPs on a selective tunnel with statically configured leafs:

The following example shows an example with dynamic selective trees and the default template:

Configuring the Master PIM Instance on the PE Router

To configure the master PIM instance that communicates with other PIM neighbors, include the pim statement at the [edit protocols] hierarchy level. BGP-based multicast VPNs support sparse mode, dense mode, or sparse-dense mode. The first example shown enables PIM sparse mode.

The next example shown enables PIM dense mode.

Configuring the Router’s IPv4 Bootstrap Router Priority

By default, the router has a bootstrap priority of 0, which means the router can never be the bootstrap router. To modify this priority, include the bootstrap-priority statement. The router with the highest priority value is elected to be the bootstrap router.