Configuring Policies for the VRF Table on PE Routers in VPNs

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]