7 mins read
OSPF Sham Link
1. Intro
We will demonstrate the Sham Link usage with the following setup. We have CE1 and CE2 router that have a backdoor link between them. The main path between CE1 and CE2 should be via the MPLS L3VPN, so we configured a high metric between CE1 and CE2, as depicted in the next figure:
Here is the configuration:
root@R4# show protocols ospf | display set
set protocols ospf area 0.0.0.0 area-range 17.8.0.0/16
set protocols ospf area 0.0.0.0 interface lo0.0 passive
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 100
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 10
root@R5# show protocols ospf | display set
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 metric 100
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 interface-type p2p
set protocols ospf area 0.0.0.0 interface ge-0/0/4.0 metric 10
set protocols ospf area 0.0.0.0 interface lo0.0
root@R1# show routing-instances CUST-A | display set
set routing-instances CUST-A instance-type vrf
set routing-instances CUST-A protocols ospf area 0.0.0.0 interface ge-0/0/3.0 interface-type p2p
set routing-instances CUST-A protocols ospf area 0.0.0.0 interface ge-0/0/3.0 metric 10
set routing-instances CUST-A protocols ospf export VRF-EXPORT-CUST-A
set routing-instances CUST-A interface ge-0/0/3.0
set routing-instances CUST-A interface lo0.100
set routing-instances CUST-A route-distinguisher 17.0.0.1:100
set routing-instances CUST-A vrf-target target:64512:100
set routing-instances CUST-A vrf-table-label
root@R6# show routing-instances CUST-A | display set
set routing-instances CUST-A instance-type vrf
set routing-instances CUST-A protocols ospf area 0.0.0.0 interface ge-0/0/2.0 interface-type p2p
set routing-instances CUST-A protocols ospf area 0.0.0.0 interface ge-0/0/2.0 metric 10
set routing-instances CUST-A protocols ospf export CUST-A-TO-OSPF
set routing-instances CUST-A interface ge-0/0/2.0
set routing-instances CUST-A interface lo0.100
set routing-instances CUST-A route-distinguisher 17.0.0.6:100
set routing-instances CUST-A vrf-target target:64512:100
set routing-instances CUST-A vrf-table-labelBut even with that high metric, the preferred path is still using the direct backdoor link.
[edit]
root@R4# run traceroute 192.168.45.5
traceroute to 192.168.45.5 (192.168.45.5), 30 hops max, 52 byte packets
1 192.168.45.5 (192.168.45.5) 3.266 ms 2.770 ms 2.376 ms
[edit]
root@R4# run show route 192.168.45.5
inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.45.5/32 *[OSPF/10] 00:05:12, metric 100
> to 17.8.3.2 via ge-0/0/2.0
### In the OSPF database we can see only the loopbacks of the CE and PE routers:
root@R4# run show ospf database
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.45.4 192.168.45.4 0x80000003 197 0x22 0xf3c6 96
Router 192.168.46.5 192.168.46.5 0x80000004 166 0x22 0xcd76 96
Router 192.168.100.1 192.168.100.1 0x80000002 210 0x22 0x2465 48
Router 192.168.100.6 192.168.100.6 0x80000002 198 0x22 0x2b4f 48
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 192.168.100.1 192.168.100.6 0x80000001 203 0xa2 0x873a 36
Extern 192.168.100.6 192.168.100.1 0x80000001 215 0xa2 0x734e 362. Test the MPLS path
We will disable the link between CE1 and CE2 then test MPLS path:
[edit]
root@R4# set interfaces ge-0/0/2 disable
[edit]
root@R4# commit
commit complete
[edit]
root@R4# run traceroute 192.168.45.5
traceroute to 192.168.45.5 (192.168.45.5), 30 hops max, 52 byte packets
1 17.18.2.1 (17.18.2.1) 2.251 ms 2.211 ms 2.354 ms
2 * * *
3 192.168.100.6 (192.168.100.6) 5.122 ms 4.903 ms 5.501 ms
4 192.168.45.5 (192.168.45.5) 6.141 ms 5.804 ms 6.296 ms
[edit]
root@R4# run show route 192.168.45.5
inet.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.45.5/32 *[OSPF/10] 00:01:01, metric 20
> to 17.18.2.1 via ge-0/0/1.0
### The MPLS path is working, but what is the issue here:
root@R4# run show ospf database
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.45.4 192.168.45.4 0x80000007 120 0x22 0x2f44 72
Router 192.168.46.5 192.168.46.5 0x80000004 573 0x22 0xcd76 96
Router 192.168.100.1 192.168.100.1 0x80000004 188 0x22 0x2067 48
Router 192.168.100.6 192.168.100.6 0x80000002 605 0x22 0x2b4f 48
Summary 17.8.3.0 192.168.100.1 0x80000001 121 0xa2 0x2241 28
Summary 128.49.243.82 192.168.100.1 0x80000001 121 0xa2 0xedd 28
Summary 192.168.45.5 192.168.100.1 0x80000001 121 0xa2 0xc087 28
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 17.8.13.0 192.168.100.1 0x80000001 121 0xa2 0xe38b 36
Extern 192.168.100.1 192.168.100.6 0x80000001 610 0xa2 0x873a 36
Extern 192.168.100.6 192.168.100.1 0x80000001 622 0xa2 0x734e 36
3. The Sham Link
As we can see in the code snippet above, the routes that are redistributed from the L3VPN BGP protocol are installed in the OSPF database as Type 3 (Summary) LSAs. Type 1 LSA (Router) are preferred over Type 3 LSA (Summary), irrespective of the metric, hence our issue.
The solution is to create a Sham Link between PE1 and PE2,
### Configure PE1:
root@R1# set routing-instances CUST-A protocols ospf sham-link local 192.168.100.1
root@R1# set routing-instances CUST-A protocols ospf area 0 sham-link-remote 192.168.100.6 metric 22
[edit]
root@R1# show | compare
[edit routing-instances CUST-A protocols ospf area 0.0.0.0]
+ sham-link-remote 192.168.100.6 metric 22;
[edit routing-instances CUST-A protocols ospf]
+ sham-link local 192.168.100.1;
[edit]
root@R1# commit
commit complete
### Same on PE2:
root@R6# set routing-instances CUST-A protocols ospf sham-link local 192.168.100.6
root@R6# set routing-instances CUST-A protocols ospf area 0 sham-link-remote 192.168.100.1 metric 22
[edit]
root@R6# commit
commit complete
### Now we can see a direct OSPF neighborship between PE 1 and PE2 using the shamlink:
root@R6# run show ospf neighbor instance CUST-A
Address Interface State ID Pri Dead
17.8.13.1 ge-0/0/2.0 Full 192.168.46.5 128 39
192.168.100.1 shamlink.0 Full 192.168.100.1 0 39
### The Sham Link appears as a 'virtual' link (don't confuse with the OSPF virtual link):
root@R1# run show ospf interface instance CUST-A extensive
Interface State Area DR ID BDR ID Nbrs
ge-0/0/3.0 PtToPt 0.0.0.0 0.0.0.0 0.0.0.0 1
Type: P2P, Address: 17.18.2.1, Mask: 255.255.255.0, MTU: 1500, Cost: 10
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None
Topology default (ID 0) -> Cost: 10
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: 22
Local: 192.168.100.1, Remote: 192.168.100.6
Adj count: 1
Hello: 10, Dead: 40, ReXmit: 5, Not Stub
Auth type: None
Protection type: None, No eligible backup, No eligible remote backup
Topology default (ID 0) -> Cost: 22
### We can see now PE1 has a direct OSPF neighborship with PE2,
### even the metric is the one we configured (22):
root@R1# run show ospf database instance CUST-A lsa-id 192.168.100.1 router extensive
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.100.1 192.168.100.1 0x80000006 24 0x22 0xe02b 60
bits 0x3, link count 3
id 192.168.45.4, data 17.18.2.1, Type PointToPoint (1)
Topology count: 0, Default metric: 10
id 17.18.2.0, data 255.255.255.0, Type Stub (3)
Topology count: 0, Default metric: 10
id 192.168.100.6, data 128.1.0.0, Type PointToPoint (1)
Topology count: 0, Default metric: 22
Topology default (ID 0)
Type: PointToPoint, Node ID: 192.168.100.6
Metric: 22, Bidirectional
Type: PointToPoint, Node ID: 192.168.45.4
Metric: 10, Bidirectional
Gen timer 00:49:35
Aging timer 00:59:35
Installed 00:00:24 ago, expires in 00:59:36, sent 00:00:24 ago
Last changed 00:00:24 ago, Change count: 6, Ours
### We no longer have the less preferred Summary LSA (Type 3) in our database:
root@R4# run show ospf database
OSPF database, Area 0.0.0.0
Type ID Adv Rtr Seq Age Opt Cksum Len
Router *192.168.45.4 192.168.45.4 0x80000009 579 0x22 0x2b46 72
Router 192.168.46.5 192.168.46.5 0x80000007 549 0x22 0xd695 84
Router 192.168.100.1 192.168.100.1 0x80000006 435 0x22 0xe02b 60
Router 192.168.100.6 192.168.100.6 0x80000005 423 0x22 0x3fc3 60
OSPF AS SCOPE link state database
Type ID Adv Rtr Seq Age Opt Cksum Len
Extern 192.168.100.1 192.168.100.6 0x80000002 1121 0xa2 0x853b 36
Extern 192.168.100.6 192.168.100.1 0x80000002 1234 0xa2 0x714f 364. Final test
Now we have the Sham link between PE1 and PE2, this should solve the issue:
### First enable the link between CE1 and CE2:
root@R4# rollback 1
load complete
[edit]
root@R4# show | compare
[edit interfaces ge-0/0/2]
- disable;
[edit]
root@R4# commit
commit complete
### The OSPF neighborship between CE1 and CE2 is back up:
root@R4# run show ospf neighbor
Address Interface State ID Pri Dead
17.18.2.1 ge-0/0/1.0 Full 192.168.100.1 128 39
17.8.3.2 ge-0/0/2.0 Full 192.168.46.5 128 31
### Let's test with a ping:
root@R4# run traceroute 192.168.45.5
traceroute to 192.168.45.5 (192.168.45.5), 30 hops max, 52 byte packets
1 17.18.2.1 (17.18.2.1) 3.997 ms 2.467 ms 2.341 ms
2 * * *
3 192.168.100.6 (192.168.100.6) 4.953 ms 4.491 ms 4.849 ms
4 192.168.45.5 (192.168.45.5) 8.813 ms 5.807 ms 6.302 ms
root@R4# run show route 192.168.45.5
inet.0: 22 destinations, 22 routes (22 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
192.168.45.5/32 *[OSPF/10] 00:05:55, metric 30
> to 17.18.2.1 via ge-0/0/1.0Now the setup is working as expected, it using the path via the L3VPN and the backdoor link is less preferred.
External Resources: