Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Configuring Routing Between PE and CE Routers

 

This topic provides information on how to configure routing on PE and CE routers \ in a Layer 3 VPN.

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:

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]

    Note

    The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

    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:

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]

    Note

    The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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:

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]

    Note

    The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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

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:

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:

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:

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

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]

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:

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

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

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]

    Note

    The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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 policies for RIP, see RIP Import Policy.

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

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]

    Note

    The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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

You can include these statements at the following hierarchy levels:

  • [edit protocols rip]

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

  • [edit logical-systems logical-system-name protocols rip]

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

Note

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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

You can include this statement at the following hierarchy levels:

  • [edit routing-options]

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

Note

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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 Junos OS Routing Protocols Library.

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]

Note

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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:

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]

Note

The [edit logical-systems] hierarchy level is not applicable in ACX Series routers.

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

Configuring an OSPF Domain ID for a Layer 3 VPN

This example illustrates how to configure an OSPF domain ID for a VPN by using OSPF as the routing protocol between the PE and CE routers. Routes from an OSPF domain need an OSPF domain ID when they are distributed in BGP as VPN-IPv4 routes in VPNs with multiple OSPF domains. In a VPN connecting multiple OSPF domains, the routes from one domain might overlap with the routes of another.

The domain ID that is configured in a routing instance identifies the OSPF domain and is used to identify the route origination. The domain ID that is configured on a community policy is used in setting exported routes.

For more information about OSPF domain IDs and Layer 3 VPNs, see Configuring Routing Between PE and CE Routers in Layer 3 VPNs.

Figure 2 shows this example’s configuration topology. Only the configuration for Router PE1 is provided. The configuration for Router PE2 can be similar to the configuration for Router PE1. There are no special configuration requirements for the CE routers.

Figure 2: Example of a Configuration Using an OSPF Domain ID
Example of a Configuration Using an
OSPF Domain ID

For configuration information, see the following sections:

Configuring Interfaces on Router PE1

You need to configure two interfaces for Router PE1—the so-0/0/0 interface for traffic to Router CE1 (San Francisco) and the so-0/0/1 interface for traffic to a P router in the service provider’s network.

Configure the interfaces for Router PE1:

Configuring Routing Options on Router PE1

At the [edit routing-options] hierarchy level, you need to configure the router-id and autonomous-system statements. The router-id statement identifies Router PE1.

Configure the routing options for Router PE1:

Configuring Protocols on Router PE1

On Router PE1, you need to configure MPLS, BGP, OSPF, and LDP at the [edit protocols] hierarchy level:

Configuring Policy Options on Router PE1

On Router PE1, you need to configure policies at the [edit policy-options] hierarchy level. These policies ensure that the CE routers in the Layer 3 VPN exchange routing information. In this example, Router CE1 in San Francisco exchanges routing information with Router CE2 in Chicago.

Configure the policy options on the PE1 router:

Configuring the Routing Instance on Router PE1

You need to configure a Layer 3 VPN routing instance on Router PE1. To indicate that the routing instance is for a Layer 3 VPN, add the instance-type vrf statement at the [edit routing-instance routing-instance-name] hierarchy level.

The domain-id statement is configured at the [edit routing-instances routing-options protocols ospf] hierarchy level. As shown in Figure 2, the routing instance on Router PE2 must share the same domain ID as the corresponding routing instance on Router PE1 so that routes from Router CE1 to Router CE2 and vice versa are distributed as Type 3 LSAs. If you configure different OSPF domain IDs in the routing instances for Router PE1 and Router PE2, the routes from each CE router will be distributed as Type 5 LSAs.

Configure the routing instance on Router PE1:

Configuration Summary for Router PE1

Configure Interfaces

Configure Routing Options

Configure Protocols

Configure VPN Policy

Routing Instance for Layer 3 VPN

You can create an intra-area link or sham link between two provider edge (PE) routing devices so that the VPN backbone is preferred over the back-door link. A back-door link is a backup link that connects customer edge (CE) devices in case the VPN backbone is unavailable. When such a backup link is available and the CE devices are in the same OSPF area, the default behavior is to prefer this backup link over the VPN backbone. This is because the backup link is considered an intra-area link, while the VPN backbone is always considered an interarea link. Intra-area links are always preferred over interarea links.

The sham link is an unnumbered point-to-point intra-area link between PE devices. When the VPN backbone has a sham intra-area link, this sham link can be preferred over the backup link if the sham link has a lower OSPF metric than the backup link.

The sham link is advertised using Type 1 link-state advertisements (LSAs). Sham links are valid only for routing instances and OSPFv2.

Each sham link is identified by the combination of a local endpoint address and a remote endpoint address. Figure 3 shows an OSPFv2 sham link. Router CE1 and Router CE2 are located in the same OSPFv2 area. These customer edge (CE) routing devices 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.

OSPFv2 treats the link through the Layer 3 VPN as an interarea link. By default, OSPFv2 prefers intra-area links to interarea links, so OSPFv2 selects the backup intra-area link as the active path. This is not acceptable in a configuration where the intra-area link is not the expected primary path for traffic between the CE routing devices. 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 routing devices.

For the remote endpoint, you can configure the OSPFv2 interface as a demand circuit, configure IPsec authentication (you configure the actual IPsec authentication separately), and define the metric value.

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

  • Two CE routing devices are linked together by a Layer 3 VPN.

  • These CE routing devices are in the same OSPFv2 area.

  • An intra-area link is configured between the two CE routing devices.

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

Note

In Junos OS Release 9.6 and later, an OSPFv2 sham link is installed in the routing table as a hidden route. Additionally, a BGP route is not exported to OSPFv2 if a corresponding OSPF sham link is available.

Note

In Junos OS Release 16.1 and later, OSPF sham-links are supported on default instances. The cost of the sham-link is dynamically set to the aigp-metric of the BGP route if no metric is configured on the sham-link by the user. If the aigp-metric is not present in the BGP route then the sham-link cost defaults to 1.

This example shows how to enable OSPFv2 sham links on a PE routing device.

Requirements

No special configuration beyond device initialization is required before configuring this example.

Overview

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 OSPFv2.

Each sham link is identified by a combination of the local endpoint address and a remote endpoint address and the OSPFv2 area to which it belongs. You manually configure the sham link between two PE devices, both of which are within the same VPN routing and forwarding (VRF) routing instance, and you 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 routing device as the sham link remote end point. You can also include the optional 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.

To enable OSPFv2 sham links on a PE routing device:

  • Configure an extra loopback interface on the PE routing device.

  • Configure the VRF routing instance that supports Layer 3 VPNs on the PE routing device, and associate the sham link with an existing OSPF area. The OSPFv2 sham link configuration is also included in the routing instance. You configure the sham link’s local endpoint address, which is the loopback address of the local VPN, and the remote endpoint address, which is the loopback address of the remote VPN. In this example, the VRF routing instance is named red.

Figure 4 shows an OSPFv2 sham link.

The devices in the figure represent the following functions:

  • CE1 and CE2 are the customer edge devices.

  • PE1 and PE2 are the provider edge devices.

  • P is the provider device.

CLI Quick Configuration shows the configuration for all of the devices in Figure 4. The section Step-by-Step Proceduredescribes the steps on Device PE1.

Configuration

CLI Quick Configuration

To quickly configure this example, copy the following commands, paste them into a text file, remove any line breaks, change any details necessary to match your network configuration, and then copy and paste the commands into the CLI at the [edit] hierarchy level.

CE1

PE1

P

PE2

CE2

Step-by-Step Procedure

The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Modifying the Junos OS Configuration in CLI User Guide.

To configure OSPFv2 sham links on each PE device:

  1. Configure the interfaces, including two loopback interfaces.
  2. Configure MPLS on the core-facing interface.
  3. Configure internal BGP (IBGP).
  4. Configure OSPF on the core-facing interface and on the loopback interface that is being used in the main instance.
  5. Configure LDP or RSVP on the core-facing interface and on the loopback interface that is being used in the main instance.
  6. Configure a routing policy for use in the routing instance.
  7. Configure the routing instance.
  8. Configure the OSPFv2 sham link.

    Include the extra loopback interface in the routing instance and also in the OSPF configuration.

    Notice that the metric on the sham-link interface is set to 10. On Device CE1’s backup OSPF link, the metric is set to 100. This causes the sham link to be the preferred link.

  9. Configure the autonomous system (AS) number and the router ID.
  10. If you are done configuring the device, commit the configuration.

Results

Confirm your configuration by entering the show interfaces and the show routing-instances commands. If the output does not display the intended configuration, repeat the instructions in this example to correct the configuration.

Output for PE1:

Verification

Confirm that the configuration is working properly.

Purpose

Verify the sham link interface. The sham link is treated as an interface in OSPFv2, with the named displayed as shamlink.<unique identifier>, where the unique identifier is a number. For example, shamlink.0. The sham link appears as a point-to-point interface.

Action

From operational mode, enter the show ospf interface instance instance-name command.

user@PE1> show ospf interface instance red

Purpose

Verify the local and remote end points of the sham link. The MTU for the sham link interface is always zero.

Action

From operational mode, enter the show ospf interface instance instance-name detail command.

user@PE1> show ospf interface shamlink.0 instance red

Purpose

Verify the adjacencies between the configured sham links.

Action

From operational mode, enter the show ospf neighbor instance instance-name command.

user@PE1> show ospf neighbor instance red

Verifying the Link-State Advertisement

Purpose

Verify that the router LSA originated by the instance carries the sham link adjacency as an unnumbered point-to-point link. The link data for sham links is a number ranging from 0x80010000 through 0x8001ffff.

Action

From operational mode, enter the show ospf database instance instance-name command.

user@PE1> show ospf database instance red

Verifying the Path Selection

Purpose

Verify that the Layer 3 VPN path is used instead of the backup path.

Action

From operational mode, enter the traceroute command from Device CE1 to Device CE2.

user@CE1> traceroute 192.0.2.5

Meaning

The traceroute operation shows that the Layer 3 VPN is the preferred path. If you were to remove the sham link or if you were to modify the OSPF metric to prefer that backup path, the traceroute would show that the backup path is preferred.

Configuring EBGP Multihop Sessions Between PE and CE Routers in Layer 3 VPNs

You can configure an EBGP or IBGP multihop session between the PE and CE routers of a Layer 3 VPN. This allows you to have one or more routers between the PE and CE routers. Using IBGP between PE and CE routers does not require the configuration of any additional statements. However, using EBGP between the PE and CE routers requires the configuration of the multihop statement.

To configure an external BGP multihop session for the connection between the PE and CE routers, include the multihop statement on the PE router. To help prevent routing loops, you have to configure a time-to-live (TTL) value for the multihop session:

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

Configuring an LDP-over-RSVP VPN Topology

This example shows how to set up a VPN topology in which LDP packets are tunneled over an RSVP LSP. This configuration consists of the following components (see Figure 5):

  • One VPN (VPN-A)

  • Two PE routers

  • LDP as the signaling protocol between the PE routers and their adjacent P routers

  • An RSVP LSP between two of the P routers over which LDP is tunneled

Figure 5: Example of an LDP-over-RSVP VPN Topology
Example of an LDP-over-RSVP VPN Topology

The following steps describe how this topology is established and how packets are sent from CE Router CE2 to CE Router CE1:

  1. The P routers P1 and P3 establish RSVP LSPs between each other and install their loopback addresses in their inet.3 routing tables.
  2. PE Router PE1 establishes an LDP session with Router P1 over interface so-1/0/0.0.
  3. Router P1 establishes an LDP session with Router P3’s loopback address, which is reachable using the RSVP LSP.
  4. Router P1 sends its label bindings, which include a label to reach Router PE1, to Router P3. These label bindings allow Router P3 to direct LDP packets to Router PE1.
  5. Router P3 establishes an LDP session with Router PE2 over interface so0-0/0/0.0 and establishes an LDP session with Router P1’s loopback address.
  6. Router P3 sends its label bindings, which include a label to reach Router PE2, to Router P1. These label bindings allow Router P1 to direct LDP packets to Router PE2’s loopback address.
  7. Routers PE1 and PE2 establish IBGP sessions with each other.
  8. When Router PE1 announces to Router PE2 routes that it learned from Router CE1, it includes its VPN label. (The PE router creates the VPN label and binds it to the interface between the PE and CE routers.) Similarly, when Router PE2 announces routes that it learned from Router CE2, it sends its VPN label to Router PE1.

When Router PE2 wants to forward a packet to Router CE1, it pushes two labels onto the packet’s label stack: first the VPN label that is bound to the interface between Router PE1 and Router CE1, then the LDP label used to reach Router PE1. Then it forwards the packets to Router P3 over interface so-0/0/1.0.

  1. When Router P3 receives the packets from Router PE2, it swaps the LDP label that is on top of the stack (according to its LDP database) and also pushes an RSVP label onto the top of the stack so that the packet can now be switched by the RSVP LSP. At this point, there are three labels on the stack: the inner (bottom) label is the VPN label, the middle is the LDP label, and the outer (top) is the RSVP label.

  2. Router P2 receives the packet and switches it to Router P1 by swapping the RSVP label. In this topology, because Router P2 is the penultimate-hop router in the LSP, it pops the RSVP label and forwards the packet over interface so-1/1/0.0 to Router P1. At this point, there are two labels on the stack: The inner label is the VPN label, and the outer one is the LDP label.

  3. When Router P1 receives the packet, it pops the outer label (the LDP label) and forwards the packet to Router PE1 using interface so-1/0/0.0. In this topology, Router PE1 is the egress LDP router, so Router P1 pops the LDP label instead of swapping it with another label. At this point, there is only one label on the stack, the VPN label.

  4. When Router PE1 receives the packet, it pops the VPN label and forwards the packet as an IPv4 packet to Router CE1 over interface ge-1/1/0.0.

A similar set of operations occurs for packets sent from Router CE1 that are destined for Router CE2.

The following list explains how, for packets being sent from Router CE2 to Router CE1, the LDP, RSVP, and VPN labels are announced by the various routers. These steps include examples of label values (illustrated in Figure 6).

  • LDP labels

    • Router PE1 announces LDP label 3 for itself to Router P1.

    • Router P1 announces LDP label 100,001 for Router PE1 to Router P3.

    • Router P3 announces LDP label 100,002 for Router PE1 to Router PE2.

  • RSVP labels

    • Router P1 announces RSVP label 3 to Router P2.

    • Router P2 announces RSVP label 100,003 to Router P3.

  • VPN label

    • Router PE1 announces VPN label 100,004 to Router PE2 for the route from Router CE1 to Router CE2.

Figure 6: Label Pushing and Popping
Label Pushing and Popping

For a packet sent from Host B in Figure 6 to Host A, the packet headers and labels change as the packet travels to its destination:

  1. The packet that originates from Host B has a source address of B and a destination address of A in its header.

  2. Router CE2 adds to the packet a next hop of interface so-1/0/0.

  3. Router PE2 swaps out the next hop of interface so-1/0/0 and replaces it with a next hop of PE1. It also adds two labels for reaching Router PE1, first the VPN label (100,004), then the LDP label (100,002). The VPN label is thus the inner (bottom) label on the stack, and the LDP label is the outer label.

  4. Router P3 swaps out the LDP label added by Router PE2 (100,002) and replaces it with its LDP label for reaching Router PE1 (100,001). It also adds the RSVP label for reaching Router P2 (100,003).

  5. Router P2 removes the RSVP label (100,003) because it is the penultimate hop in the MPLS LSP.

  6. Router P1 removes the LDP label (100,001) because it is the penultimate LDP router. It also swaps out the next hop of PE1 and replaces it with the next-hop interface, so-1/0/0.

  7. Router PE1 removes the VPN label (100,004). It also swaps out the next-hop interface of so-1/0/0 and replaces it with its next-hop interface, ge-1/1/0.

  8. Router CE1 removes the next-hop interface of ge-1/1/0, and the packet header now contains just a source address of B and a destination address of A.

The final section in this example consolidates the statements needed to configure VPN functionality on each of the service P routers shown in Figure 5.

Note

In this example, a private AS number is used for the route distinguisher and the route target. This number is used for illustration only. When you are configuring VPNs, you should use an assigned AS number.

The following sections explain how to configure the VPN functionality on the PE and P routers. The CE routers do not have any information about the VPN, so you configure them normally.

Enabling an IGP on the PE and P Routers

To allow the PE and P routers to exchange routing information among themselves, you must configure an IGP on all these routers or you must configure static routes. You configure the IGP on the primary instance of the routing protocol process (rpd) (that is, at the [edit protocols] hierarchy level), not within the VPN routing instance (that is, not at the [edit routing-instances] hierarchy level).

You configure the IGP in the standard way. This configuration example does not include this portion of the configuration.

Enabling LDP on the PE and P Routers

In this configuration example, the LDP is the signaling protocol between the PE routers. For the VPN to function, you must configure LDP on the two PE routers and on the P routers that are connected to the PE routers. You need to configure LDP only on the interfaces in the core of the service provider’s network; that is, between the PE and P routers and between the P routers. You do not need to configure LDP on the interface between the PE and CE routers.

In this configuration example, you configure LDP on the P routers’ loopback interfaces because these are the interfaces on which the MPLS LSP is configured.

On the PE routers, you must also configure family inet when you configure the logical interface.

On Router PE1, configure LDP:

On Router PE2, configure LDP:

On Router P1, configure LDP:

On Router P3, configure LDP:

On Router P2, although you do not need to configure LDP, you can optionally configure it to provide a fallback LDP path in case the RSVP LSP becomes nonoperational:

Enabling RSVP and MPLS on the P Router

On the P Router P2 you must configure RSVP and MPLS because this router exists on the MPLS LSP path between the P Routers P1 and P3:

Configuring the MPLS LSP Tunnel Between the P Routers

In this configuration example, LDP is tunneled over an RSVP LSP. Therefore, in addition to configuring RSVP, you must enable traffic engineering support in an IGP, and you must create an MPLS LSP to tunnel the LDP traffic.

On Router P1, enable RSVP and configure one end of the MPLS LSP tunnel. In this example, traffic engineering support is enabled for OSPF, and you configure MPLS on the interfaces to the LSP and to Router PE1. In the to statement, you specify the loopback address of Router P3.

On Router P3, enable RSVP and configure the other end of the MPLS LSP tunnel. Again, traffic engineering support is enabled for OSPF, and you configure MPLS on the interfaces to the LSP and to Router PE2. In the to statement, you specify the loopback address of Router P1.

Configuring IBGP on the PE Routers

On the PE routers, configure an IBGP session with the following properties:

  • VPN family—To indicate that the IBGP session is for the VPN, include the family inet-vpn statement.

  • Loopback address—Include the local-address statement, specifying the local PE router’s loopback address. The IBGP session for VPNs runs through the loopback address. You must also configure the lo0 interface at the [edit interfaces] hierarchy level. The example does not include this part of the router’s configuration.

  • Neighbor address—Include the neighbor statement, specifying the IP address of the neighboring PE router, which is its loopback (lo0) address.

On Router PE1, configure IBGP:

On Router PE2, configure IBGP:

Configuring Routing Instances for VPNs on the PE Routers

Both PE routers service VPN-A, so you must configure one routing instance on each router for the VPN in which you define the following:

  • Route distinguisher, which must be unique for each routing instance on the PE router. It is used to distinguish the addresses in one VPN from those in another VPN.

  • Instance type of vrf, which creates the VRF table on the PE router.

  • Interfaces connected to the CE routers.

  • VRF import and export policies, which must be the same on each PE router that services the same VPN. Unless the import policy contains only a then reject statement, it must include reference to a community. Otherwise, when you try to commit the configuration, the commit fails.

    Note

    In this example, a private AS number is used for the route distinguisher. This number is used for illustration only. When you are configuring VPNs, you should use an assigned AS number.

  • Routing between the PE and CE routers, which is required for the PE router to distribute VPN-related routes to and from connected CE routers. You can configure a routing protocol—BGP, OSPF, or RIP—or you can configure static routing.

On Router PE1, configure the following routing instance for VPN-A. In this example, Router PE1 uses RIP to distribute routes to and from the CE router to which it is connected.

On Router PE2, configure the following routing instance for VPN-A. In this example, Router PE2 uses OSPF to distribute routes to and from the CE router to which it is connected.

Configuring VPN Policy on the PE Routers

You must configure VPN import and export policies on each of the PE routers so that they install the appropriate routes in their VRF tables, which they use to forward packets within a VPN. For VPN-A, the VRF table is VPN-A.inet.0.

In the VPN policy, you also configure VPN target communities.

Note

In this example, a private AS number is used for the route target. This number is used for illustration only. When you are configuring VPNs, you should use an assigned AS number.

On Router PE1, configure the following VPN import and export policies:

Note

The policy qualifiers shown in this example are only those needed for the VPN to function. You can configure additional qualifiers, as needed, to any policies that you configure.

On Router PE2, configure the following VPN import and export policies:

To apply the VPN policies on the routers, include the vrf-export and vrf-import statements when you configure the routing instance on the PE routers. The VRF import and export policies handle the route distribution across the IBGP session running between the PE routers.

LDP-over-RSVP VPN Configuration Summarized by Router

Router PE1

Routing Instance for VPN-A

Instance Routing Protocol

Interfaces

Primary Protocol Instance

Enable LDP

Enable MPLS

Configure IBGP

Configure VPN Policy

Router P1

Primary Protocol Instance

Enable RSVP

Enable LDP

Enable MPLS

Configure OSPF for Traffic Engineering Support

Router P2

Primary Protocol Instance

Enable RSVP

Enable MPLS

Router P3

Primary Protocol Instance

Enable RSVP

Enable LDP

Enable MPLS

Configure OSPF for Traffic Engineering Support

Router PE2

Routing Instance for VPN-A

Instance Routing Protocol

Interfaces

Primary Protocol Instance

Enable LDP

Enable MPLS

Configure IBGP

Configure VPN Policy

Configuring an Application-Based Layer 3 VPN Topology

This example illustrates an application-based mechanism for forwarding traffic into a Layer 3 VPN. Typically, one or more interfaces are associated with, or bound to, a VPN by including them in the configuration of the VPN routing instance. By binding the interface to the VPN, the VPN’s VRF table is used to make forwarding decisions for any incoming traffic on that interface. Binding the interface also includes the interface local routes in the VRF table, which provides next-hop resolution for VRF routes.

In this example, a firewall filter is used to define which incoming traffic on an interface is forwarded by means of the standard routing table, inet.0, and which incoming traffic is forwarded by means of the VRF table. You can expand this example such that incoming traffic on an interface can be redirected to one or more VPNs. For example, you can define a configuration to support a VPN that forwards traffic based on source address, that forwards Hypertext Transfer Protocol (HTTP) traffic, or that forwards only streaming media.

For this configuration to work, the following conditions must be true:

  • The interfaces that use filter-based forwarding must not be bound to the VPN.

  • Static routing must be used as the means of routing.

  • You must define an interface routing table group that is shared among inet.0 and the VRF tables to provide local routes to the VRF table.

This example consists of two client hosts (Client D and Client E) that are in two different VPNs and that want to send traffic both within the VPN and to the Internet. The paths are defined as follows:

  • Client A sends traffic to Client E over VPN A with a return path that also uses VPN A (using the VPN’s VRF table).

  • Client B sends traffic to Client D over VPN B with a return path that uses standard destination-based routing (using the inet.0 routing table).

  • Clients B and C send traffic to the Internet using standard routing (using the inet.0 routing table), with a return path that also uses standard routing.

This example illustrates that there are a large variety of options in configuring an application-based Layer 3 VPN topology. This flexibility has application in many network implementations that require specific traffic to be forwarded in a constrained routing environment.

This configuration example shows only the portions of the configuration for the filter-based forwarding, routing instances, and policy. It does not illustrate how to configure a Layer 3 VPN.

Figure 7 illustrates the network topology used in this example.

Figure 7: Application-Based Layer 3 VPN Example Configuration
Application-Based Layer 3 VPN
Example Configuration

Configuration on Router A

On Router A, you configure the interface to Clients A, B, and C. The configuration evaluates incoming traffic to determine whether it is to be forwarded by means of VPN or standard destination-based routing.

First, you apply an inbound filter and configure the interface:

Because the interfaces that use filter-based forwarding must not be bound to a VPN, you must configure an alternate method to provide next-hop routes to the VRF table. You do this by defining an interface routing table group and sharing this group among all the routing tables:

You apply the following filter to incoming traffic on interface fe-1/1/0.0. The first term matches traffic from Client A and forwards it to the routing instance for VPN A. The second term matches traffic from Client B that is destined for Client D and forwards it to the routing instance for VPN B. The third term matches all other traffic, which is forwarded normally by means of destination-based forwarding according to the routes in inet.0.

You then configure the routing instances for VPN A and VPN B. Notice that these statements include all the required statements to define a Layer 3 VPN except for the interface statement.

Configuration on Router E

On Router E, configure a default route to reach the Internet. You should inject this route into the local IBGP mesh to provide an exit point from the network.

Configure the interface to Client E so that all incoming traffic on interface fe-1/1/1.0 that matches the VPN policy is forwarded over VPN A:

Configuration on Router F

Again, because the interfaces that use filter-based forwarding must not be bound to a VPN, you configure an alternate method to provide next-hop routes to the VRF table by defining an interface routing table group and sharing this group among all the routing tables. To provide a route back to the clients for normal inet.0 routing, you define a static route to include in inet.0 and redistribute the static route into BGP:

To direct traffic from VPN B to Client D, you configure the routing instance for VPN B on Router F. All incoming traffic from Client D on interface so-3/3/3.0 is forwarded normally by means of the destination address based on the routes in inet.0.