Distributing VPN Routes

Using LDP for VPN Signaling

To use LDP for VPN signaling, perform the following steps on the PE and provider (P) routers:

1. Configure LDP on the interfaces in the core of the service provider’s network by including the ldp statement at the [edit protocols] hierarchy level.

   You need to configure LDP only on the interfaces between PE routers or between PE and P routers. You can think of these as the “core-facing” interfaces. You do not need to configure LDP on the interface between the PE and customer edge (CE) routers.

2. Configure the MPLS address family on the interfaces on which you enabled LDP (the interfaces you configured in Step 1) by including the family mpls statement at the [edit interfaces type-fpc/pic/port unit logical-unit-number] hierarchy level.

3. Configure OSPF or IS-IS on each PE and P router.

   You configure these protocols at the master instance of the routing protocol, not within the routing instance used for the VPN.

   • To configure OSPF, include the ospf statement at the [edit protocols] hierarchy level. At a minimum, you must configure a backbone area on at least one of the router’s interfaces.

   • To configure IS-IS, include the isis statement at the [edit protocols] hierarchy level and configure the loopback interface and International Organization for Standardization (ISO) family at the [edit interfaces] hierarchy level. At a minimum, you must enable IS-IS on the router, configure a network entity title (NET) on one of the router’s interfaces (preferably the loopback interface, lo0), and configure the ISO family on all interfaces on which you want IS-IS to run. When you enable IS-IS, Level 1 and Level 2 are enabled by default. The following is the minimum IS-IS configuration. In the address statement, address is the NET.

Using RSVP for VPN Signaling

To use RSVP for VPN signaling, perform the following steps:

1. On each PE router, configure traffic engineering.

   To do this, you must configure an interior gateway protocol (IGP) that supports traffic engineering (either IS-IS or OSPF) and enable traffic engineering support for that protocol.

   To enable OSPF traffic engineering support, include the traffic-engineering statement at the [edit protocols ospf] hierarchy level:

   For IS-IS, traffic engineering support is enabled by default.

2. On each PE and P router, enable RSVP on the interfaces that participate in the label-switched path (LSP).

   On the PE router, these interfaces are the ingress and egress points to the LSP. On the P router, these interfaces connect the LSP between the PE routers. Do not enable RSVP on the interface between the PE and the CE routers, because this interface is not part of the LSP.

   To configure RSVP on the PE and P routers, include the interface statement at the [edit protocols rsvp] hierarchy level. Include one interface statement for each interface on which you are enabling RSVP.

3. On each PE router, configure an MPLS LSP to the PE router that is the LSP’s egress point.

   To do this, include the interface and label-switched-path statements at the [edit protocols mpls] hierarchy level:

   In the to statement, specify the address of the LSP’s egress point, which is an address on the remote PE router.

   In the interface statement, specify the name of the interface (both the physical and logical portions). Include one interface statement for the interface associated with the LSP.

   When you configure the logical portion of the same interface at the [edit interfaces] hierarchy level, you must also configure the family inet and family mpls statements:

4. On all P routers that participate in the LSP, enable MPLS by including the interface statement at the [edit mpls] hierarchy level.

   Include one interface statement for each connection to the LSP.

5. Enable MPLS on the interface between the PE and CE routers by including the interface statement at the [edit mpls] hierarchy level.

   Doing this allows the PE router to assign an MPLS label to traffic entering the LSP or to remove the label from traffic exiting the LSP.

   For information about configuring MPLS, see the Configuring the Ingress Router for MPLS-Signaled LSPs.

Configuring the Route Target

As part of the policy configuration for the VPN routing table, you must define a route target, which defines which VPN the route is a part of. When you configure different types of VPN services (Layer 2 VPNs, Layer 3 VPNs, EVPNs, or VPLS) on the same PE router, be sure to assign unique route target values to avoid the possibility of adding route and signaling information to the wrong VPN routing table.

To configure the route target, include the target option in the community statement:

You can include this statement at the following hierarchy levels:

• [edit policy-options]

• [edit logical-systems logical-system-name policy-options]

name is the name of the community.

community-id is the identifier of the community. Specify it in one of the following formats:

• as-number:number, where as-number is an AS number (a 2-byte value) and number is a 4-byte community value. The AS number can be in the range 1 through 65,535. We recommend that you use an IANA-assigned, nonprivate AS number, preferably the ISP’s own or the customer’s own AS number. The community value can be a number in the range 0 through 4,294,967,295 (2³² – 1).

• ip-address:number, where ip-address is an IPv4 address (a 4-byte value) and number is a 2-byte community value. The IP address can be any globally unique unicast address. We recommend that you use the address that you configure in the router-id statement, which is a nonprivate address in your assigned prefix range. The community value can be a number in the range 1 through 65,535.

Configuring the Route Origin

In the import and export policies for the PE router’s VRF table, you can optionally assign the route origin (also known as the site of origin) for a PE router’s VRF routes using a VRF export policy applied to multiprotocol external BGP (MP-EBGP) VPN IPv4 route updates sent to other PE routers.

Matching on the assigned route origin attribute in a receiving PE’s VRF import policy helps ensure that VPN-IPv4 routes learned through MP-EBGP updates from one PE are not reimported to the same VPN site from a different PE connected to the same site.

To configure a route origin, complete the following steps:

1. Include the community statement with the origin option:

   You can include this statement at the following hierarchy levels:

   • [edit policy-options]

   • [edit logical-systems logical-system-name policy-options]

   name is the name of the community.

   community-id is the identifier of the community. Specify it in one of the following formats:

   • as-number:number, where as-number is an AS number (a 2-byte value) and number is a 4-byte community value. The AS number can be in the range 1 through 65,535. We recommend that you use an IANA-assigned, nonprivate AS number, preferably the ISP’s own or the customer’s own AS number. The community value can be a number in the range 0 through 4,294,967,295 (2³² – 1).

   • ip-address:number, where ip-address is an IPv4 address (a 4-byte value) and number is a 2-byte community value. The IP address can be any globally unique unicast address. We recommend that you use the address that you configure in the router-id statement, which is a nonprivate address in your assigned prefix range. The community value can be a number in the range 1 through 65,535.

2. Include the community in the import policy for the PE router’s VRF table by configuring the community statement with the community-id identifier defined in Step 1 at the [edit policy-options policy-statement import-policy-name term import-term-name from] hierarchy level. See Configuring an Import Policy for the PE Router’s VRF Table.

   If the policy’s from clause does not specify a community condition, the vrf-import statement in which the policy is applied cannot be committed. The Junos OS commit operation does not pass the validation check.

3. Include the community in the export policy for the PE router’s VRF table by configuring the community statement with the community-id identifier defined in Step 1 at the [edit policy-options policy-statement export-policy-name term export-term-name then] hierarchy level. See Configuring an Export Policy for the PE Router’s VRF Table.

See Configuring the Route Origin for VPNs for a configuration example.

Configuring an Import Policy for the PE Router’s VRF Table

Each VPN can have a policy that defines how routes are imported into the PE router’s VRF table. An import policy is applied to routes received from other PE routers in the VPN. A policy must evaluate all routes received over the IBGP session with the peer PE router. If the routes match the conditions, the route is installed in the PE router’s routing-instance-name.inet.0 VRF table. An import policy must contain a second term that rejects all other routes.

Unless an import policy contains only a then reject statement, it must include a reference to a community. Otherwise, when you try to commit the configuration, the commit fails. You can configure multiple import policies.

An import policy determines what to import to a specified VRF table based on the VPN routes learned from the remote PE routers through IBGP. The IBGP session is configured at the [edit protocols bgp] hierarchy level. If you also configure an import policy at the [edit protocols bgp] hierarchy level, the import policies at the [edit policy-options] hierarchy level and the [edit protocols bgp] hierarchy level are combined through a logical AND operation. This allows you to filter traffic as a group.

To configure an import policy for the PE router’s VRF table, follow these steps:

1. To define an import policy, include the policy-statement statement. For all PE routers, an import policy must always include the policy-statement statement, at a minimum:

   You can include the policy-statement statement at the following hierarchy levels:

   • [edit policy-options]

   • [edit logical-systems logical-system-name policy-options]

   The import-policy-name policy evaluates all routes received over the IBGP session with the other PE router. If the routes match the conditions in the from statement, the route is installed in the PE router’s routing-instance-name.inet.0 VRF table. The second term in the policy rejects all other routes.

   For more information about creating policies, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

2. You can optionally use a regular expression to define a set of communities to be used for the VRF import policy.

   For example you could configure the following using the community statement at the [edit policy-options policy-statement policy-statement-name] hierarchy level:

   Note that you cannot configure a regular expression as a part of a route target extended community. For more information about how to configure regular expressions for communities, see Understanding How to Define BGP Communities and Extended Communities .

3. To configure an import policy, include the vrf-import statement:

   You can include this statement at the following hierarchy levels:

   • [edit routing-instances routing-instance-name]

   • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Configuring an Export Policy for the PE Router’s VRF Table

Each VPN can have a policy that defines how routes are exported from the PE router’s VRF table. An export policy is applied to routes sent to other PE routers in the VPN. An export policy must evaluate all routes received over the routing protocol session with the CE router. (This session can use the BGP, OSPF, or Routing Information Protocol [RIP] routing protocols, or static routes.) If the routes match the conditions, the specified community target (which is the route target) is added to them and they are exported to the remote PE routers. An export policy must contain a second term that rejects all other routes.

Export policies defined within the VPN routing instance are the only export policies that apply to the VRF table. Any export policy that you define on the IBGP session between the PE routers has no effect on the VRF table. You can configure multiple export policies.

To configure an export policy for the PE router’s VRF table, follow these steps:

1. For all PE routers, an export policy must distribute VPN routes to and from the connected CE routers in accordance with the type of routing protocol that you configure between the CE and PE routers within the routing instance.

   To define an export policy, include the policy-statement statement. An export policy must always include the policy-statement statement, at a minimum:

   Note:

   Configuring the community add statement is a requirement for Layer 2 VPN VRF export policies. If you change the community add statement to the community set statement, the router at the egress of the Layer 2 VPN link might drop the connection.

   Note:

   When configuring draft-rosen multicast VPNs operating in source-specific mode and using the vrf-export statement to specify the export policy, the policy must have a term that accepts routes from the vrf-name.mdt.0 routing table. This term ensures proper PE autodiscovery using the inet-mdt address family.

   When configuring draft-rosen multicast VPNs operating in source-specific mode and using the vrf-target statement, the VRF export policy is automatically generated and automatically accepts routes from the vrf-name.mdt.0 routing table.

   You can include the policy-statement statement at the following hierarchy levels:

   • [edit policy-options]

   • [edit logical-systems logical-system-name policy-options]

   The export-policy-name policy evaluates all routes received over the routing protocol session with the CE router. (This session can use the BGP, OSPF, or RIP routing protocols, or static routes.) If the routes match the conditions in the from statement, the community target specified in the then community add statement is added to them and they are exported to the remote PE routers. The second term in the policy rejects all other routes.

   For more information about creating policies, see the Routing Policies, Firewall Filters, and Traffic Policers User Guide.

2. To apply the policy, include the vrf-export statement:

   You can include this statement at the following hierarchy levels:

   • [edit routing-instances routing-instance-name]

   • [edit logical-systems logical-system-name routing-instances routing-instance-name]

Applying Both the VRF Export and the BGP Export Policies

When you apply a VRF export policy as described in Configuring an Export Policy for the PE Router’s VRF Table, routes from VPN routing instances are advertised to other PE routers based on this policy, whereas the BGP export policy is ignored.

If you include the vpn-apply-export statement in the BGP configuration, both the VRF export and BGP group or neighbor export policies are applied (VRF first, then BGP) before routes are advertised in the VPN routing tables to other PE routers.

When you include the vpn-apply-export statement, be aware of the following:

• Routes imported into the bgp.l3vpn.0 routing table retain the attributes of the original routes (for example, an OSPF route remains an OSPF route even when it is stored in the bgp.l3vpn.0 routing table). You should be aware of this when you configure an export policy for connections between an IBGP PE router and a PE router, a route reflector and a PE router, or AS boundary router (ASBR) peer routers.

• By default, all routes in the bgp.l3vpn.0 routing table are exported to the IBGP peers. If the last statement of the export policy is deny all and if the export policy does not specifically match on routes in the bgp.l3vpn.0 routing table, no routes are exported.

To apply both the VRF export and BGP export policies to VPN routes, include the vpn-apply-export statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Configuring a VRF Target

Including the vrf-target statement in the configuration for a VRF target community causes default VRF import and export policies to be generated that accept and tag routes with the specified target community. You can still create more complex policies by explicitly configuring VRF import and export policies. These policies override the default policies generated when you configure the vrf-target statement.

If you do not configure the import and export options of the vrf-target statement, the specified community string is applied in both directions. The import and export keywords give you more flexibility, allowing you to specify a different community for each direction.

The syntax for the VRF target community is not a name. You must specify it in the format target:x:y. A community name cannot be specified because this would also require you to configure the community members for that community using the policy-options statement. If you define the policy-options statements, then you can just configure VRF import and export policies as usual. The purpose of the vrf-target statement is to simplify the configuration by allowing you to configure most statements at the [edit routing-instances] hierarchy level.

To configure a VRF target, include the vrf-target statement:

You can include this statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name]

• [edit logical-systems logical-system-name routing-instances routing-instance-name]

An example of how you might configure the vrf-target statement follows:

To configure the vrf-target statement with the export and import options, include the following statements:

You can include this statement at the following hierarchy levels:

• [edit routing-instances routing-instance-name]

• [edit logical-systems logical-system-name routing-instances routing-instance-name]

Configuring the Site of Origin Community on CE Router A

The following section describes how to configure CE Router A to advertise routes with a site of origin community to PE Router B for this example.

Configure a policy to advertise routes with my-soo community on CE Router A as follows:

Configuring the Community on CE Router A

Configure the my-soo community on CE Router A as follows:

Applying the Policy Statement on CE Router A

Apply the export-to-my-isp policy statement as an export policy to the EBGP peering on the CE Router A as follows:

When you issue the show route receive-protocol bgp detail command, you should see the following routes originated from PE Router B with my-soo community:

Configuring the Policy on PE Router D

Configure a policy on PE Router D that prevents routes with my-soo community tagged by CE Router A from being advertised to CE Router E as follows:

Configuring the Community on PE Router D

Configure the community on PE Router D as follows:

Applying the Policy on PE Router D

To prevent routes learned from CE Router A from being advertised to CE Router E (the two routers can communicate these routes directly), apply the soo-ce1-policy policy statement as an export policy to the PE Router D and CE Router E EBGP session vpn_blue.

View the EBGP session on PE Router D using the show routing-instances command.

Apply the soo-ce1-policy policy statement as an export policy to the PE Router D and CE Router E EBGP session vpn_blue as follows: