MPLS VPN OSPF Sham Link
Table of Contents
Introduction
OSPF Sham links are used in MPLS VPNs using OSPF where both sites have a backdoor link and routing preference should be given to the MPLS path instead of backdoor link.
Sham Link
- Sham links try to fix a situation where two MPLS VPN sites belong to the same area and have two paths to each other: MPLS VPN and backdoor link. In such a situation LSA advertised through backdoor links will be LSA 1 and LSA 2 while the MPLS VPN path LSA 3 always preferring the backdoor link.
- Sham links allow for flooding of LSA types 1 and 2 over a "fake link", when MPLS VPN and backdoor links can use the same type of LSA to evaluate which path to prefer. Cost for sham links and backdoor links can be modified to set the preferences.
- Sham-Links are only point to point.
- Similar solution to virtual-links, similar configuration is little different than virtual-links, source and destination IP are interface IP (not RID), that belong to the VRF. These interfaces (loopback) should not be advertised into that instance of OSPF (just like any tunneling endpoint addresses).
- Sham-link needs to be in the same area (for non-zero areas). If different areas are configured, then they have to be in area 0 (this might require virtual-links).
Configuration
- To configure a sham link, create a new loopbacks on each PE, use a /32 address.
- Add these loopback interface to the customer vrf.
- Advertise the loopback into BGP address-family of the vrf. This could be done redistribute static or a bgp network. If redistributing static and using a route-map to limit interfaces, make sure to include the outgoing interface or else MPLS won't aggregate label and forwarding will be broken.
- Specify the /32 loopback source and destination ip address along with it's area and cost under the OSPF vrf process. If different areas are being connected with a sham link, use area 0 and make sure they have a virtual-link to connect them to area 0.
- The /32 endpoint addressing has to be present in MP-BGP not advertised by OSPF. If OSPF knows about these prefixes natively (LSA 3),the sham link establishment will loop up and down as iBGP AD is higher then OSPF. Use BGP of that same vrf to advertise this prefix (network command of a /32). These loopback can be redistributed into OSPF but can't be natively advertised by it.
- Make sure BGP is redistributed into OSPF, as for Sham link to come up it need to be an ASBR.
- Best thing to do is to filter the redistribution of the Sham-link loopbacks from being redistributed into ospf. Create a route-map to deny them when redistributing into OSPF from BGP. This could cause issues where sham hello's won't be even send.
Troubleshooting
- Verify that mpls ip forwarding is functional (good way to do so is with ping mpls to the other PE). You might have an instance where sham-link is up but the PE router is still not choosing to use it. With mpls ip forwarding disabled you'll still get a sham-link up see below:
Rack1R5#sh ip ospf sham
Sham Link OSPF_SL0 to address 150.1.44.44 is up
Area 90 source address 150.1.55.55
Run as demand circuit
DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Hello due in 00:00:00
<---------Not fully adj
Rack1R5#sh ip ospf sham
Sham Link OSPF_SL0 to address 150.1.44.44 is up
Area 90 source address 150.1.55.55
Run as demand circuit
DoNotAge LSA allowed. Cost of using 1 State POINT_TO_POINT,
Timer intervals configured, Hello 10, Dead 40, Wait 40,
Hello due in 00:00:07
Adjacency State FULL (Hello suppressed) <---------Now fully adj, after enabling mpls ip
Index 2/2, retransmission queue length 0, number of retransmission 0
First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)
Last retransmission scan length is 0, maximum is 0
Last retransmission scan time is 0 msec, maximum is 0 msec
Relevant Commands
area sham-link
R1(config)# area (#) sham-link (src/32) (dst/32) [cost (cost)]