TechLibrary

Navigation

Supported Platforms

Configuring Routing Between PE and CE Routers in Layer 3 VPNs

For the PE router to distribute VPN-related routes to and from connected CE routers, you must configure routing within the VPN routing instance. You can configure a routing protocol—BGP, OSPF, or RIP—or you can configure static routing. For the connection to each CE router, you can configure only one type of routing.

The following sections explain how to configure VPN routing between the PE and CE routers:

Configuring BGP Between the PE and CE Routers

To configure BGP as the routing protocol between the PE and the CE routers, include the bgp statement:

bgp {group group-name {peer-as as-number;neighbor ip-address;}}

You can include this statement at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols]
Please be aware of the following limitations regarding configuring BGP for routing instances:
- In a VRF routing instance, do not configure the local autonomous system (AS) number using an AS number that is already in use by a remote BGP peer in a separate VRF routing instance. Doing so creates an autonomous system loop where all the routes received from this remote BGP peer are hidden.
  You configure the local AS number using either the autonomous-system statement at the [edit routing-instances routing-instance-name routing-options] hierarchy level or the local-as statement at any of the following hierarchy levels:
  - [edit routing-instances routing-instance-name protocols bgp]
  - [edit routing-instances routing-instance-name protocols bgp group group-name]
  - [edit routing-instances routing-instance-name protocols bgp group group-name neighbor address]
  You configure the AS number for a BGP peer using the peer-as statement at the [edit routing-instances routing-instance-name protocols bgp group group-name] hierarchy level.

Configuring OSPF Between the PE and CE Routers

You can configure OSPF (version 2 or version 3) to distribute VPN-related routes between PE and CE routers.

The following sections describe how to configure OSPF as a routing protocol between the PE and the CE routers:

Configuring OSPF Version 2 Between the PE and CE Routers

To configure OSPF version 2 as the routing protocol between a PE and CE router, include the ospf statement:

ospf {area area {interface interface-name;}}

You can include this statement at the following hierarchy levels:

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

Configuring OSPF Version 3 Between the PE and CE Routers

To configure OSPF version 3 as the routing protocol between a PE and CE router, include the ospf3 statement:

ospf3 {area area {interface interface-name;}}

You can include this statement at the following hierarchy levels:

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

Configuring OSPF Sham Links for Layer 3 VPNs

When you configure OSPF between the PE and CE routers of a Layer 3 VPN, you can also configure OSPF sham links to compensate for issues related to OSPF intra-area links.

The following sections describe OSPF sham links and how to configure them:

OSPF Sham Links Overview

Figure 1 provides an illustration of when you might configure an OSPF sham link. Router CE1 and Router CE2 are located in the same OSPF area. These CE routers are linked together by a Layer 3 VPN over Router PE1 and Router PE2. In addition, Router CE1 and Router CE2 are connected by an intra-area link used as a backup.

OSPF treats the link through the Layer 3 VPN as an interarea link. By default, OSPF prefers intra-area links to interarea links, so OSPF selects the backup intra-area link as the active path. This is not acceptable in configurations where the intra-area link is not the expected primary path for traffic between the CE routers.

An OSPF sham link is also an intra-area link, except that it is configured between the PE routers as shown in Figure 1. You can configure the metric for the sham link to ensure that the path over the Layer 3 VPN is preferred to a backup path over an intra-area link connecting the CE routers.

Figure 1: OSPF Sham Link

You should configure an OSPF sham link under the following circumstances:

Two CE routers are linked together by a Layer 3 VPN.
These CE routers are in the same OSPF area.
An intra-area link is configured between the two CE routers.

If there is no intra-area link between the CE routers, you do not need to configure an OSPF sham link.

For more information about OSPF sham links, see the Internet draft draft-ietf-l3vpn-ospf-2547-01.txt, OSPF as the PE/CE Protocol in BGP/MPLS VPNs.

Configuring OSPF Sham Links

The sham link is an unnumbered point-to-point intra-area link and is advertised by means of a type 1 link-state advertisement (LSA). Sham links are valid only for routing instances and OSPF version 2.

Each sham link is identified by a combination of the local and remote sham link end-point address and the OSPF area to which it belongs. Sham links must be configured manually. You configure the sham link between two PE routers, both of which are within the same VRF routing instance.

You need to specify the address for the local end point of the sham link. This address is used as the source for the sham link packets and is also used by the remote PE router as the sham link remote end-point.

The OSPF sham link’s local address must be specified with a loopback address for the local VPN. The route to this address must be propagated by BGP. Specify the address for the local end point using the local option of the sham-link statement:

sham-link {local address;}

You can include this statement at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols ospf]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

The OSPF sham link’s remote address must be specified with a loopback address for the remote VPN. The route to this address must be propagated by BGP. To specify the address for the remote end point, include the sham-link-remote statement:

sham-link-remote address <metric number>;

You can include this statement at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols ospf area area-id]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf area area-id]

Optionally, you can include the metric option to set a metric value for the remote end point. The metric value specifies the cost of using the link. Routes with lower total path metrics are preferred over those with higher path metrics.

You can configure a value from 1 through 65,535. The default value is 1.

OSPF Sham Links Example

This example shows how to enable OSPF sham links on a PE router.

The following is the loopback interface configuration on the PE router. The address configured is for the local end point of the OSPF sham link:

[edit]interfaces {lo0 {unit 1 {family inet {address 10.1.1.1/32;}}}}

The following is the routing instance configuration on the PE router, including the configuration for the OSPF sham link. The sham-link local statement is configured with the address for the local loopback interface:

[edit]routing-instances {example-sham-links {instance-type vrf;interface e1-1/0/2.0;interface lo0.1;route-distinguisher 3:4;vrf-import vpn-red-import;vrf-export vpn-red-export;protocols {ospf {sham-link local 10.1.1.1;area 0.0.0.0 {sham-link-remote 10.2.2.2 metric 1;interface e1-1/0/2.0 metric 1;}}}}}

Configuring an OSPF Domain ID

For most OSPF configurations involving Layer 3 VPNs, you do not need to configure an OSPF domain ID. However, for a Layer 3 VPN connecting multiple OSPF domains, configuring OSPF domain IDs can help you control LSA translation (for Type 3 and Type 5 LSAs) between the OSPF domains and back-door paths.

Without the domain IDs, there is no way to identify which domain the routes originated from after the OSPF or OSPFv3 routes are distributed into BGP routes and advertised across the BGP VPN backbone. Distinguishing which OSPF or OSPFv3 domain a route originated from allows classification of routes as Type 3 LSAs or Type 5 LSAs.

Each VPN routing and forwarding (VRF) table in a PE router associated with an OSPF instance is configured with the same OSPF domain ID. The default OSPF domain ID is the null value 0.0.0.0. As shown in Table 1, a route with a null domain ID is handled differently from a route without any domain ID at all.

Table 1: How a PE Router Redistributes and Advertises Routes

Route Received	Domain ID of the Route Received	Domain ID on the Receiving Router	Route Redistributed and Advertised As
Type 3 route	A.B.C.D	A.B.C.D	Type 3 LSA
Type 3 route	A.B.C.D	E.F.G.H	Type 5 LSA
Type 3 route	0.0.0.0	0.0.0.0	Type 3 LSA
Type 3 route	Null	0.0.0.0	Type 3 LSA
Type 3 route	Null	Null	Type 3 LSA
Type 3 route	0.0.0.0	Null	Type 3 LSA
Type 3 route	A.B.C.D	Null	Type 5 LSA
Type 3 route	Null	A.B.C.D	Type 5 LSA
Type 5 route	Not applicable	Not applicable	Type 5 LSA

To summarize:

If the receiving PE router sees a Type 3 route with a matching domain ID, the route is redistributed and advertised as a Type 3 LSA.
If the receiving PE router sees a Type 3 route without a domain ID (the extended attribute field of the route’s BGP update does not include a domain ID), the route is redistributed and advertised as a Type 3 LSA.
If the receiving PE router sees a Type 3 route with a non-matching domain ID, the route is redistributed and advertised as a Type 5 LSA.
If the receiving PE router sees a Type 3 route with a domain ID, but the router does not have a domain ID configured, the route is redistributed and advertised as a Type 5 LSA.
If the receiving PE router sees a Type 5 route, the route is redistributed and advertised as a Type 5 LSA, regardless of the domain ID.

You can configure an OSPF domain ID for both version 2 and version 3 of OSPF. The only difference in the configuration is that you include statements at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level for OSPF version 2 and at the [edit routing-instances routing-instance-name protocols ospf3] hierarchy level for OSPF version 3. The configuration descriptions that follow present the OSPF version 2 statement only. However, the substatements are also valid for OSPF version 3.

To configure a domain ID, perform the following tasks:

Specify a domain ID in the BGP extended community ID.
Set a route type.
Configure a VRF export policy to explicitly attach the outbound extended community ID to outbound routes.
Define a community with members that possess the community ID.

The extended community ID can then be carried across the BGP VPN backbone. When the route is redistributed back as an OSPF or OSPFv3 route on the PE router and advertised to the CE near the destination, the domain ID identifies which domain the route originated from. The routing instance checks incoming routes for the domain ID. The route is then propagated as either a Type 3 LSA or Type 5 LSA.

To configure an OSPF domain ID, include the domain-id statement:

domain-id domain-Id;

For domain-id, specify either an IP address or an IP address and a local identifier using the following format: ip-address:local-identifier. If you do not specify a local identifier with the IP address, the identifier is assumed to have a value of 0.

You can include this statement at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols ospf]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

On the local PE router, the prefix of the directly connected PE/CE interface is an active direct route. This route is also an OSPF or OSPFv3 route.

In the VRF export policy, the direct prefix is exported to advertise the route to the remote PE. This route is injected as an AS-External-LSA, much as when a direct route is exported into OSPF or OSPFv3.

Domain ID ensures that an originated summary LSA arrives at the remote PE as a summary LSA. Domain ID does not translate AS-external-LSAs into summary LSAs.

If the router ID is not configured in the routing instance, the router ID is derived from an interface address belonging to the routing instance.

To prevent routing loops when a domain ID is used as an alternate route preference for the OSPF or OSPFv3 external routes generated by the PE router, the DN bit of the LSA being distributed by the PE router must be set. If the route is distributed in a Type 5 LSA and the DN bit is not supported by the PE router, the VPN tag is used instead.

You can set a VPN tag for the OSPF external routes generated by the PE router to prevent looping. By default, this tag is automatically calculated and needs no configuration. However, you can configure the domain VPN tag for Type 5 LSAs explicitly by including the domain-vpn-tag statement:

domain-vpn-tag number;

You can include this statement at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols ospf]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols ospf]

The range is 1 through 4,294,967,295 (2³² – 1). If you set VPN tags manually, you must set the same value for all PE routers in the VPN.

To clear the VPN tag when it is no longer needed (when the DN bit is supported on the PE router), include the no-domain-vpn-tag statement:

no-domain-vpn-tag;

The DN bit is not currently supported in OSPFv3.

To set the route type, include the route-type-community statement:

route-type-community (iana | vendor);

You can include the statement at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols (ospf | ospf3)]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols (ospf | ospf3)]

The domain-id setting in the routing instance is for a match on inbound Layer 3 VPN routes. A VRF export policy must be explicitly set for the outbound extended community domain-id attribute. You must configure an export policy to attach the domain ID to outgoing routes. To configure an export policy to attach the domain ID and route distinguisher to the extended community ID on outbound routes, include the community statement:

policy-statement policy-name {term term-name {from protocol (ospf | ospf3);then {community add community-name;accept;}}term b {then reject;}}community community-name members [ target:target-id domain-id:domain-id];

To define the members of a community, include the community statement:

community name {members [ community-ids ];}

Examples: Configuring an OSPF Domain ID

Configure a domain ID as a match condition for inbound Layer 3 VPN routes. Then configure an export policy to tag the extended community ID and the route distinguisher onto outgoing routes:

[edit]routing-instances {CE_A {instance-type vrf;interface ge-0/1/0.0;route-distinguisher 1:100;vrf-import vrf_import_routes;vrf-export vrf_export_routes;protocols {ospf {domain-id 1.1.1.1; # match for inbound routesroute-type-community vendor;export vrf_import_routes;area 0.0.0.0 {interface ge-0/1/0.0;}}}}}policy-options {policy-statement vrf_export_routes {term a {from protocol ospf;then {community add export_target;accept;}}term b {then reject;}}community export_target members [ target:1:100 domain-id:1.1.1.1:0 ];}

Leak a noninstance route into the instance routing table:

[edit]routing-options {interface-routes {rib-group inet inet_to_site_A;}}[edit]rib-groups {inet_to_site_A {import-rib [ inet.0 site_A.inet.0 ];}}[edit]protocols {ospf {rib-group inet_to_site_A;}}[edit]policy-options {policy-statement announce_to_ce {term a {from {protocol direct;interface lo0.0;}then accept;}}}[edit]routing-instances {site_A {protocols {ospf {export announce_to_ce;}}}}

Hub-and-Spoke Layer 3 VPNs and OSPF Domain IDs

The default behavior of an OSPF domain ID causes some problems for hub-and-spoke Layer 3 VPNs configured with OSPF between the hub PE router and the hub CE router when the routes are not aggregated. A hub-and-spoke configuration has a hub PE router with direct links to a hub CE router. The hub PE router receives Layer 3 BGP updates from the other remote spoke PE routers, and these are imported into the spoke routing instance. From the spoke routing instance, the OSPF LSAs are originated and sent to the hub CE router.

The hub CE router typically aggregates these routes, and then sends these newly originated LSAs back to the hub PE router. The hub PE router exports the BGP updates to the remote spoke PE routers containing the aggregated prefixes. However, if there are nonaggregated Type 3 summary LSAs or external LSAs, two issues arise with regard to how the hub PE router originates and sends LSAs to the hub CE router, and how the hub PE router processes LSAs received from the hub CE router:

By default, all LSAs originated by the hub PE router in the spoke routing instance have the DN bit set. Also, all externally originated LSAs have the VPN route tag set. These settings help prevent routing loops. For Type 3 summary LSAs, routing loops are not a concern because the hub CE router, as an area border router (ABR), reoriginates the LSAs with the DN bit clear and sends them back to the hub PE router. However, the hub CE router does not reoriginate external LSAs, because they have an AS flooding scope.
You can originate the external LSAs (before sending them to the hub CE router) with the DN bit clear and the VPN route tag set to 0 by altering the hub PE router’s routing instance configuration. To clear the DN bit and set the VPN route tag to zero on external LSAs originated by a PE router, configure 0 for the domain-vpn-tag statement at the [edit routing-instances routing-instance-name protocols ospf] hierarchy level. You should include this configuration in the routing instance on the hub PE router facing the hub CE router where the LSAs are sent. When the hub CE router receives external LSAs from the hub PE router and then forwards them back to the hub PE router, the hub PE router can use the LSAs in its OSPF route calculation.
When LSAs flooded by the hub CE router arrive at the hub PE router’s routing instance, the hub PE router, acting as an ABR, does not consider these LSAs in its OSPF route calculations, even though the LSAs do not have the DN bits set and the external LSAs do not have a VPN route tag set. The LSAs are assumed to be from a disjoint backbone area.
You can change the configuration of the PE router’s routing instance to cause the PE router to act as a non-ABR by including the disable statement at the [edit routing-instances routing-instance-name protocols ospf domain-id] hierarchy level. You make this configuration change to the hub PE router that receives the LSAs from the hub CE router.
By making this configuration change, the PE router’s routing instance acts as a non-ABR. The PE router then considers the LSAs arriving from the hub CE router as if they were coming from a contiguous nonbackbone area.

Configuring RIP Between the PE and CE Routers

For a Layer 3 VPN, you can configure RIP on the PE router to learn the routes of the CE router or to propagate the routes of the PE router to the CE router. RIP routes learned from neighbors configured at any [edit routing-instances] hierarchy level are added to the routing instance’s inet table (instance_name.inet.0).

To configure RIP as the routing protocol between the PE and the CE router, include the rip statement:

rip {group group-name {export policy-names;neighbor interface-name;}}

You can include this statement at the following hierarchy levels:

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

By default, RIP does not advertise the routes it receives. To advertise routes from a PE router to a CE router, you need to configure an export policy on the PE router for RIP. For information about how to define an export policy, see the Junos OS Policy Framework Configuration Guide .

To specify an export policy for RIP, include the export statement:

export [ policy-names ];

You can include this statement for RIP at the following hierarchy levels:

[edit routing-instances routing-instance-name protocols rip group group-name]
[edit logical-systems logical-system-name routing-instances routing-instance-name protocols rip group group-name]

To install routes learned from a RIP routing instance into multiple routing tables, include the rib-group and group statements:

rib-group inet group-name;group group-name {neighbor interface-name;}

You can include these statements at the following hierarchy levels:

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

To configure a routing table group, include the rib-groups statement:

rib-groups group-name;

You can include this statement at the following hierarchy levels:

[edit routing-options]
[edit logical-systems logical-system-name routing-options]

To add a routing table to a routing table group, include the import-rib statement. The first routing table name specified under the import-rib statement must be the name of the routing table you are configuring. For more information about how to configure routing tables and routing table groups, see the Junos OS Routing Protocols Configuration Guide .

import-rib [ group-names ];

You can include this statement at the following hierarchy levels:

[edit routing-options rib-groups group-name]
[edit logical-systems logical-system-name routing-options rib-groups group-name]

RIP instances are supported only for VRF instance types. You can configure multiple instances of RIP for VPN support only. You can use RIP in the customer edge-provider edge (CE-PE) environment to learn routes from the CE router and to propagate the PE router’s instance routes in the CE router.

RIP routes learned from neighbors configured under any instance hierarchy are added to the instance’s routing table, instance-name.inet.0.

RIP does not support routing table groups; therefore, it cannot import routes into multiple tables as the OSPF or OSPFv3 protocol does.

Configuring Static Routes Between the PE and CE Routers

You can configure static (nonchanging) routes between the PE and CE routers of a VPN routing instance. To configure a static route for a VPN, you need to configure it within the VPN routing instance configuration at the [edit routing-instances routing-instance-name routing-options] hierarchy level.

To configure a static route between the PE and the CE routers, include the static statement:

static {route destination-prefix {next-hop [ next-hops ];static-options;}}

You can include this statement at the following hierarchy levels:

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

For more information about configuring routing protocols and static routes, see the Junos OS Routing Protocols Configuration Guide .

TechLibrary

Supported Platforms

Configuring Routing Between PE and CE Routers in Layer 3 VPNs

Configuring BGP Between the PE and CE Routers

Configuring OSPF Between the PE and CE Routers

Configuring OSPF Version 2 Between the PE and CE Routers

Configuring OSPF Version 3 Between the PE and CE Routers

Configuring OSPF Sham Links for Layer 3 VPNs

OSPF Sham Links Overview

Configuring OSPF Sham Links

OSPF Sham Links Example

Configuring an OSPF Domain ID

Examples: Configuring an OSPF Domain ID

Hub-and-Spoke Layer 3 VPNs and OSPF Domain IDs

Configuring RIP Between the PE and CE Routers

Configuring Static Routes Between the PE and CE Routers

Published: 2012-06-27

Supported Platforms

Published: 2012-06-27