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.
user@PE1> show route table vpna.mvpn.0
vpna.mvpn.0: 6 destinations, 9 routes (6 active, 1 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
1:10.1.1.1:1:10.1.1.1/240
*[MVPN/70] 04:09:44, metric2 1
IndirectAttaching 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:
user@PE1> show policy __vrf-mvpn-import-target-vpna-internal__ Policy __vrf-mvpn-import-target-vpna-internal__: Term unnamed: from community __vrf-mvpn-community-import-vpna-internal__ [target:10:2 ] then accept Term unnamed: then reject user@PE1> show policy __vrf-mvpn-export-target-vpna-internal__ Policy __vrf-mvpn-export-target-vpna-internal__: Term unnamed: then community + __vrf-mvpn-community-export-vpna-internal__ [target:10:2 ] accept
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.
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 10.1.1.1:65535:mvpn:vpna
with two sub-LSPs. Both sub-LSPs 10.1.1.3:10.1.1.1:65535:mvpn:vpna and 10.1.1.2:10.1.1.1:65535:mvpn:vpna use the same RSVP
port number (6574) as the parent point-to-multipoint LSP.
user@PE1> show rsvp session p2mp detail Ingress RSVP: 2 sessions P2MP name: 10.1.1.1:65535:mvpn:vpna, P2MP branch count: 2 10.1.1.3 From: 10.1.1.1, LSPstate: Up, ActiveRoute: 0 LSPname: 10.1.1.3:10.1.1.1:65535:mvpn:vpna, LSPpath: Primary P2MP LSPname: 10.1.1.1:65535:mvpn:vpna Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299968 Resv style: 1 SE, Label in: -, Label out: 299968 Time left: -, Since: Wed May 27 07:36:22 2009 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 6574 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.12.100.6 (fe-0/2/3.0) 27 pkts RESV rcvfrom: 10.12.100.6 (fe-0/2/3.0) 27 pkts Explct route: 10.12.100.6 10.12.100.22 Record route: <self> 10.12.100.6 10.12.100.22 10.1.1.2 From: 10.1.1.1, LSPstate: Up, ActiveRoute: 0 LSPname: 10.1.1.2:10.1.1.1:65535:mvpn:vpna, LSPpath: Primary P2MP LSPname: 10.1.1.1:65535:mvpn:vpna Suggested label received: -, Suggested label sent: - Recovery label received: -, Recovery label sent: 299968 Resv style: 1 SE, Label in: -, Label out: 299968 Time left: -, Since: Wed May 27 07:36:22 2009 Tspec: rate 0bps size 0bps peak Infbps m 20 M 1500 Port number: sender 1 receiver 6574 protocol 0 PATH rcvfrom: localclient Adspec: sent MTU 1500 Path MTU: received 1500 PATH sentto: 10.12.100.6 (fe-0/2/3.0) 27 pkts RESV rcvfrom: 10.12.100.6 (fe-0/2/3.0) 27 pkts Explct route: 10.12.100.6 10.12.100.9 Record route: <self> 10.12.100.6 10.12.100.9 Total 2 displayed, Up 2, Down 0 Egress RSVP: 0 sessions Total 0 displayed, Up 0, Down 0 Transit RSVP: 0 sessions Total 0 displayed, Up 0, Down 0
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.