Example: Giving VPN Backbones Priority with OSPFv2 Sham Links for Layer 3 VPNs
OSPFv2 Sham Links Overview
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.
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.
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.
Example: Configuring OSPFv2 Sham Links
This example shows how to enable OSPFv2 sham links on a PE routing device.
No special configuration beyond device initialization is required before configuring this example.
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
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  hierarchy level.
To configure OSPFv2 sham links on each PE device:
- Configure the interfaces, including two loopback interfaces.[edit interfaces]user@PE1# set fe-1/2/0 unit 0 family inet address 10.1.1.2/30user@PE1# set fe-1/2/0 unit 0 family mplsuser@PE1# set fe-1/2/1 unit 0 family inet address 10.1.1.5/30user@PE1# set fe-1/2/1 unit 0 family mplsuser@PE1# set lo0 unit 0 family inet address 192.0.2.2/24user@PE1# set lo0 unit 1 family inet address 198.51.100.2/24
- Configure MPLS on the core-facing interface.[edit protocols mpls]user@PE1# set interface fe-1/2/1.0
- Configure internal BGP (IBGP).[edit ]user@PE1# set protocols bgp group toR4 type internaluser@PE1# set protocols bgp group toR4 local-address 192.0.2.2user@PE1# set protocols bgp group toR4 family inet-vpn unicastuser@PE1# set protocols bgp group toR4 neighbor 192.0.2.4
- Configure OSPF on the core-facing interface and on the
loopback interface that is being used in the main instance.[edit protocols ospf area 0.0.0.0]user@PE1# set interface fe-1/2/1.0user@PE1# set interface lo0.0 passive
- Configure LDP or RSVP on the core-facing interface and
on the loopback interface that is being used in the main instance.[edit protocols ldp]user@PE1# set interface fe-1/2/1.0user@PE1# set interface lo0.0
- Configure a routing policy for use in the routing instance.[edit policy-options policy-statement bgp-to-ospf]user@PE1# set term 1 from protocol bgpuser@PE1# set term 1 then acceptuser@PE1# set term 2 then reject
- Configure the routing instance.[edit routing-instances red]user@PE1# set instance-type vrfuser@PE1# set interface fe-1/2/0.0user@PE1# set route-distinguisher 2:1user@PE1# set vrf-target target:2:1user@PE1# set protocols ospf export bgp-to-ospfuser@PE1# set protocols ospf area 0.0.0.0 interface fe-1/2/0.0
- 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.
- Configure the autonomous system (AS) number and the router
ID.[edit routing-options]user@PE1# set router-id 192.0.2.2user@PE1# set autonomous-system 2
- If you are done configuring the device, commit the configuration.user@R1# commit
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:
Confirm that the configuration is working properly.
Verifying the Sham Link Interfaces
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.
From operational mode, enter the show ospf interface instance instance-name command.
user@PE1> show ospf interface instance red
Interface State Area DR ID BDR ID Nbrs lo0.1 DR 0.0.0.0 198.51.100.2 0.0.0.0 0 fe-1/2/0.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Verifying the Local and Remote End Points of the Sham Link
Verify the local and remote end points of the sham link. The MTU for the sham link interface is always zero.
From operational mode, enter the show ospf interface instance instance-name detail command.
user@PE1> show ospf interface shamlink.0 instance red
Interface State Area DR ID BDR ID Nbrs shamlink.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1 Type: P2P, Address: 0.0.0.0, Mask: 0.0.0.0, MTU: 0, Cost: 10 Local: 198.51.100.2, Remote: 198.51.100.4 Adj count: 1 Hello: 10, Dead: 40, ReXmit: 5, Not Stub Auth type: None Protection type: None, No eligible backup Topology default (ID 0) -> Cost: 10
Verifying the Sham Link Adjacencies
Verify the adjacencies between the configured sham links.
From operational mode, enter the show ospf neighbor instance instance-name command.
user@PE1> show ospf neighbor instance red
Address Interface State ID Pri Dead 10.1.1.1 fe-1/2/0.0 Full 192.0.2.1 128 35 198.51.100.4 shamlink.0 Full 198.51.100.4 0 31
Verifying the Link-State Advertisement
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.
From operational mode, enter the show ospf database instance instance-name command.
user@PE1> show ospf database instance red
OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 192.0.2.1 192.0.2.1 0x80000009 1803 0x22 0x6ec7 72 Router 192.0.2.5 192.0.2.5 0x80000007 70 0x22 0x2746 72 Router *198.51.100.2 198.51.100.2 0x80000006 55 0x22 0xda6b 60 Router 198.51.100.4 198.51.100.4 0x80000005 63 0x22 0xb19 60 Network 10.0.0.18 192.0.2.5 0x80000002 70 0x22 0x9a71 32 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 198.51.100.2 198.51.100.4 0x80000002 72 0xa2 0x343 36 Extern *198.51.100.4 198.51.100.2 0x80000002 71 0xa2 0xe263 36
Verifying the Path Selection
Verify that the Layer 3 VPN path is used instead of the backup path.
From operational mode, enter the traceroute command from Device CE1 to Device CE2.
user@CE1> traceroute 192.0.2.5
traceroute to 192.0.2.5 (192.0.2.5), 30 hops max, 40 byte packets 1 10.1.1.2 (10.1.1.2) 1.930 ms 1.664 ms 1.643 ms 2 * * * 3 10.1.1.10 (10.1.1.10) 2.485 ms 1.435 ms 1.422 ms MPLS Label=299808 CoS=0 TTL=1 S=1 4 192.0.2.5 (192.0.2.5) 1.347 ms 1.362 ms 1.329 ms
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.