Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Navigation

Example: Configuring OSPFv2 Sham Links

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.

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.

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

set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.1/30set interfaces fe-1/2/0 unit 0 family mplsset interfaces fe-1/2/1 unit 0 family inet address 10.0.0.17/30set interfaces lo0 unit 0 family inet address 1.1.1.1/32set protocols ospf area 0.0.0.0 interface fe-1/2/0.0set protocols ospf area 0.0.0.0 interface lo0.0 passiveset protocols ospf area 0.0.0.0 interface fe-1/2/1.0 metric 100set policy-options policy-statement send-direct from protocol directset policy-options policy-statement send-direct then acceptset routing-options router-id 1.1.1.1set routing-options autonomous-system 1

PE1

set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.2/30set interfaces fe-1/2/0 unit 0 family mplsset interfaces fe-1/2/1 unit 0 family inet address 10.1.1.5/30set interfaces fe-1/2/1 unit 0 family mplsset interfaces lo0 unit 0 family inet address 1.1.1.2/32set interfaces lo0 unit 1 family inet address 2.2.2.2/32set protocols mpls interface fe-1/2/1.0set protocols bgp group toR4 type internalset protocols bgp group toR4 local-address 1.1.1.2set protocols bgp group toR4 family inet-vpn unicastset protocols bgp group toR4 neighbor 1.1.1.4set protocols ospf area 0.0.0.0 interface fe-1/2/1.0set protocols ospf area 0.0.0.0 interface lo0.0 passiveset protocols ldp interface fe-1/2/1.0set protocols ldp interface lo0.0set policy-options policy-statement bgp-to-ospf term 1 from protocol bgpset policy-options policy-statement bgp-to-ospf term 1 then acceptset policy-options policy-statement bgp-to-ospf term 2 then rejectset routing-instances red instance-type vrfset routing-instances red interface fe-1/2/0.0set routing-instances red interface lo0.1set routing-instances red route-distinguisher 2:1set routing-instances red vrf-target target:2:1set routing-instances red protocols ospf export bgp-to-ospfset routing-instances red protocols ospf sham-link local 2.2.2.2set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 4.4.4.4 metric 10set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/0.0set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1set routing-options router-id 1.1.1.2set routing-options autonomous-system 2

P

set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.6/30set interfaces fe-1/2/0 unit 0 family mplsset interfaces fe-1/2/1 unit 0 family inet address 10.1.1.9/30set interfaces fe-1/2/1 unit 0 family mplsset interfaces lo0 unit 3 family inet address 1.1.1.3/32set protocols mpls interface allset protocols ospf area 0.0.0.0 interface lo0.3 passiveset protocols ospf area 0.0.0.0 interface allset protocols ldp interface allset routing-options router-id 1.1.1.3

PE2

set interfaces fe-1/2/0 unit 0 family inet address 10.1.1.10/30set interfaces fe-1/2/0 unit 0 family mplsset interfaces fe-1/2/1 unit 0 family inet address 10.1.1.13/30set interfaces fe-1/2/1 unit 0 family mplsset interfaces lo0 unit 0 family inet address 1.1.1.4/32set interfaces lo0 unit 1 family inet address 4.4.4.4/32set protocols mpls interface fe-1/2/0.0set protocols bgp group toR2 type internalset protocols bgp group toR2 local-address 1.1.1.4set protocols bgp group toR2 family inet-vpn unicastset protocols bgp group toR2 neighbor 1.1.1.2set protocols ospf area 0.0.0.0 interface lo0.0 passiveset protocols ospf area 0.0.0.0 interface fe-1/2/0.0set protocols ldp interface fe-1/2/0.0set protocols ldp interface lo0.0set policy-options policy-statement bgp-to-ospf term 1 from protocol bgpset policy-options policy-statement bgp-to-ospf term 1 then acceptset policy-options policy-statement bgp-to-ospf term 2 then rejectset routing-instances red instance-type vrfset routing-instances red interface fe-1/2/1.0set routing-instances red interface lo0.1set routing-instances red route-distinguisher 2:1set routing-instances red vrf-target target:2:1set routing-instances red protocols ospf export bgp-to-ospfset routing-instances red protocols ospf sham-link local 4.4.4.4set routing-instances red protocols ospf area 0.0.0.0 sham-link-remote 2.2.2.2 metric 10set routing-instances red protocols ospf area 0.0.0.0 interface fe-1/2/1.0set routing-instances red protocols ospf area 0.0.0.0 interface lo0.1set routing-options router-id 1.1.1.4set routing-options autonomous-system 2

CE2

set interfaces fe-1/2/0 unit 14 family inet address 10.1.1.14/30set interfaces fe-1/2/0 unit 14 family mplsset interfaces fe-1/2/0 unit 18 family inet address 10.0.0.18/30set interfaces lo0 unit 5 family inet address 1.1.1.5/32set protocols ospf area 0.0.0.0 interface fe-1/2/0.14set protocols ospf area 0.0.0.0 interface lo0.5 passiveset protocols ospf area 0.0.0.0 interface fe-1/2/0.18set policy-options policy-statement send-direct from protocol directset policy-options policy-statement send-direct then acceptset routing-options router-id 1.1.1.5set routing-options autonomous-system 3

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.
    [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 1.1.1.2/32user@PE1# set lo0 unit 1 family inet address 2.2.2.2/32
  2. Configure MPLS on the core-facing interface.
    [edit protocols mpls]user@PE1# set interface fe-1/2/1.0
  3. Configure internal BGP (IBGP).
    [edit ]user@PE1# set protocols bgp group toR4 type internaluser@PE1# set protocols bgp group toR4 local-address 1.1.1.2user@PE1# set protocols bgp group toR4 family inet-vpn unicastuser@PE1# set protocols bgp group toR4 neighbor 1.1.1.4
  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
  5. 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
  6. 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
  7. 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
  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.

    [edit routing-instances red]user@PE1# set interface lo0.1user@PE1# set protocols ospf sham-link local 2.2.2.2user@PE1# set protocols ospf area 0.0.0.0 sham-link-remote 4.4.4.4 metric 10user@PE1# set protocols ospf area 0.0.0.0 interface lo0.1
  9. Configure the autonomous system (AS) number and the router ID.
    [edit routing-options]user@PE1# set router-id 1.1.1.2user@PE1# set autonomous-system 2
  10. If you are done configuring the device, commit the configuration.
    [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:

user@PE1# show interfaces fe-1/2/0 {unit 0{family inet {address 10.1.1.2/30;}family mpls;}}fe-1/2/1 {unit 0 {family inet {address 10.1.1.5/30;}family mpls;}}lo0 {unit 0 {family inet {address 1.1.1.2/32;}}unit 1 {family inet {address 2.2.2.2/32;}}}
user@PE1# show protocols mpls {interface fe-1/2/1.0;}bgp {group toR4 {type internal;local-address 1.1.1.2;family inet-vpn {unicast;}neighbor 1.1.1.4;}}ospf {area 0.0.0.0 {interface fe-1/2/1.0;interface lo0.0 {passive;}}}ldp {interface fe-1/2/1.0;interface lo0.0;}
user@PE1# show policy-options policy-statement bgp-to-ospf {term 1 {from protocol bgp;then accept;}term 2 {then reject;}}
user@PE1# show routing-instances red {instance-type vrf;interface fe-1/2/0.0;interface lo0.1;route-distinguisher 2:1;vrf-target target:2:1;protocols {ospf {export bgp-to-ospf;sham-link local 2.2.2.2;area 0.0.0.0 {sham-link-remote 4.4.4.4 metric 10;interface fe-1/2/0.0;interface lo0.1;}}}}
user@PE1# show routing-options router-id 1.1.1.2;autonomous-system 2;

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 red
Interface           State   Area            DR ID           BDR ID          Nbrs
lo0.1              DR      0.0.0.0         2.2.2.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 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: 2.2.2.2, Remote: 4.4.4.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 red
Address          Interface              State     ID               Pri  Dead
10.1.1.1         fe-1/2/0.0             Full      1.1.1.1          128    35
4.4.4.4          shamlink.0             Full      4.4.4.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   1.1.1.1          1.1.1.1          0x80000009  1803  0x22 0x6ec7  72
Router   1.1.1.5          1.1.1.5          0x80000007    70  0x22 0x2746  72
Router  *2.2.2.2          2.2.2.2          0x80000006    55  0x22 0xda6b  60
Router   4.4.4.4          4.4.4.4          0x80000005    63  0x22 0xb19   60
Network  10.0.0.18        1.1.1.5          0x80000002    70  0x22 0x9a71  32
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern   2.2.2.2          4.4.4.4          0x80000002    72  0xa2 0x343   36
Extern  *4.4.4.4          2.2.2.2          0x80000002    71  0xa2 0xe263  36

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 1.1.1.5
traceroute to 1.1.1.5 (1.1.1.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  1.1.1.5 (1.1.1.5)  1.347 ms  1.362 ms  1.329 ms

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.

Published: 2012-12-08

Published: 2012-12-08