Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Example: Giving VPN Backbones Priority with OSPFv2 Sham Links for Layer 3 VPNs

 

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

See also

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