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:

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:

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:

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 19 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 19. 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 19: OSPF Sham Link

Image g017173.gif

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

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:

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:

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 1-.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. 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 3, a route with a null domain ID is handled differently from a route without any domain ID at all.

Table 3: 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

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 an OSPF domain ID, include the domain-id statement:

domain-id domain-Id;

You can include this statement at the following hierarchy levels:

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:

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

For an example of this type of configuration, see Configuring an OSPF Domain ID for a Layer 3 VPN.

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:

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:

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 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:

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:

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:

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 Routing Protocols Configuration Guide.

import-rib [ group-names ];

You can include this statement at the following hierarchy levels:

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:

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

Copyright© 1999-2010 Juniper Networks, Inc. All rights reserved.