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.
See also
For more information about Layer 3 VPNs, see the Junos OS VPNs Library for Routing Devices
Example: Configuring OSPFv2 Sham Links
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:
- Configure the interfaces, including two loopback interfaces.content_copy zoom_out_map[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.content_copy zoom_out_map[edit protocols mpls]user@PE1# set interface fe-1/2/1.0
- Configure internal BGP (IBGP).content_copy zoom_out_map[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.content_copy zoom_out_map[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.content_copy zoom_out_map[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.content_copy zoom_out_map[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.content_copy zoom_out_map[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.
content_copy zoom_out_map[edit routing-instances red]user@PE1# set interface lo0.1user@PE1# set protocols ospf sham-link local 198.51.100.2user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 198.51.100.4 metric 10user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1 - Configure the autonomous system (AS) number and the router
ID.content_copy zoom_out_map[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.content_copy zoom_out_map[edit]user@R1# commit
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.
Verifying the Sham Link Interfaces
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 redInterface 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
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
redInterface 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
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 redAddress 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
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 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 36Verifying 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.5traceroute 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 msMeaning
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.
