Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?


Originating Type 1 Intra-AS Autodiscovery Routes Overview

Every provider edge (PE) router that is participating in the next-generation multicast virtual private network (MVPN) is required to originate a Type 1 intra-AS autodiscovery route. In Junos OS, the MVPN module is responsible for installing the intra-AS autodiscovery route in the local <routing-instance-name>.mvpn.0 table. All PE routers advertise their local Type 1 routes to each other. Routers referenced in this topic are shown in Understanding Next-Generation MVPN Network Topology.

Use the show route table vpna.mvpn.0 command to verify that Router PE1 has installed intra-AS AD routes in the vpna.mvpn.0 table. The route is installed by the MVPN protocol (meaning it is the MVPN module that originated the route), and the mask for the entire route is /240.

Attaching Route Target Community to Type 1 Routes

Intra-AS AD routes are picked up by the BGP protocol from the <routing-instance-name>.mvpn.0 table and advertised to the remote PE routers via the MCAST-VPN address family. By default, intra-AS autodiscovery routes carry the same route target community that is attached to the unicast VPN-IPv4 routes. If the unicast and multicast network topologies are not congruent, then you can configure a different set of import route target and export route target communities for non-C-multicast MVPN routes (C-multicast MVPN routes always carry a dynamic import route target).

Multicast route targets are configured by including the import-target and export-target statements at the [edit routing-instances routing-instance-name protocols mvpn route-target] hierarchy level.

Junos OS creates two additional internal policies in response to configuring multicast route targets. These policies are applied to non-C-multicast MVPN routes during import and export decisions. Multicast VPN routing and forwarding (VRF) internal import and export polices follow a naming convention similar to unicast VRF import and export policies. The contents of these polices are also similar to policies applied to unicast VPN routes.

The following list identifies the default policy names and where they are applied:

Multicast VRF import policy: __vrf-mvpn-import-target-<routing-instance-name>-internal__

Multicast VRF export policy: __vrf-mvpn-export-target-<routing-instance-name>-internal__

Use the show policy __vrf-mvpn-import-target-vpna-internal__ command on Router PE1 to verify that Router PE1 has created the following internal MVPN policies if import-target and export-target are configured to be target:10:2:

The values in this example are as follows:

  • Multicast import RT community: __vrf-mvpn-community-import-vpna-internal__

  • Multicast export RT community: __vrf-mvpn-community-export-vpna-internal__ Value: target:10:2

Attaching the PMSI Attribute to Type 1 Routes

The provider multicast service interface (PMSI) attribute is originated and attached to Type 1 intra-AS autodiscovery routes by the sender PE routers when the provider-tunnel statement is included at the [edit routing-instances routing-instance-name] hierarchy level. Since provider tunnels are signaled by the sender PE routers, this statement is not necessary on the PE routers that are known to have VPN multicast receivers only.

If the provider tunnel configured is Protocol Independent Multicast-Sparse Mode (PIM-SM) any-source multicast (ASM), then the PMSI attribute carries the IP address of the sender-PE and provider tunnel group address. The provider tunnel group address is assigned by the service provider (through configuration) from the provider’s multicast address space and is not to be confused with the multicast addresses used by the VPN customer.

If the provider tunnel configured is the RSVP-Traffic Engineering (RSVP-TE) type, then the PMSI attribute carries the RSVP-TE point-to-multipoint session object. This point-to-multipoint session object is used as the identifier for the parent point-to-multipoint label-switched path (LSP) and contains the fields shown in Figure 1.

Figure 1: RSVP-TE Point-to-Multipoint Session Object FormatRSVP-TE Point-to-Multipoint Session Object Format

In Junos OS, the P2MP ID and Extended Tunnel ID fields are set to the router ID of the sender PE router. The Tunnel ID is set to the port number used for the point-to-multipoint RSVP session that is unique for the length of the RSVP session.

Use the show rsvp session p2mp detail command to verify that Router PE1 signals the following RSVP sessions to Router PE2 and Router PE3 (using port number 6574). In this example, Router PE1 is signaling a point-to-multipoint LSP named with two sub-LSPs. Both sub-LSPs and use the same RSVP port number (6574) as the parent point-to-multipoint LSP.

Sender-Only and Receiver-Only Sites

In Junos OS, you can configure a PE router to be a sender-site only or a receiver-site only. These options are enabled by including the sender-site and receiver-site statements at the [edit routing-instances routing-instance-name protocols mvpn] hierarchy level.

  • A sender-site only PE router does not join the provider tunnels advertised by remote PE routers

  • A receiver-site only PE router does not send a PMSI attribute

The commit fails if you include the receiver-site and provider-tunnel statements in the same VPN.