MPLS Sham Link Issues Once OSPF Session is established on both ends of the link

[OwenTaylor]

I have two locations that was recently activated for a client using MPLS L3 vpns,  the end to end circuit is working fine showing the remote network via bgp and is reachable via ping.

I then established an OSPF session on both end of the link with the client devices, immediately I realize that all routes including the ones assigned to the layer3 interfaces assigned to the PE routers are now using the client layer2 Link as its primary path,

I then configured a sham link thinking that this would be the solution, however the /32 for the sham links loopbacks and the /30 prefixes assigned to the interface interconnecting both client sites are all using the other carrier that the client has.

Because of this the sham links are not being established as the path is not via the MPLS network , if I disconnect one side of the client's link the sham link is established  along with the /30 prefixes for the demarc interfaces is present via bgp within the client vrf.

[Eason_W]

sham link

1、loopback /32

2、bgp network mask/32

3、ospf vrf process config 

[OwenTaylor · Accepted solution]

The issue is that the routes for all interfaces are learning via the L2 backdoor links, how do i over come that.
==============PE1-============
vrf definition EX-SPIRIT
description London Ave Link1
rd 100:2200
!
address-family ipv4
route-target export 100:2200
route-target import 100:2200
exit-address-family
!
!

!
interface GigabitEthernet0/0/0.2200
encapsulation dot1Q 2200
vrf forwarding EX-SPIRIT
ip address 10.16.220.1 255.255.255.252

!
interface Loopback2200
vrf forwarding EX-SPIRIT
ip address 10.1.1.2 255.255.255.255
!
router ospf 2200 vrf EX-SPIRIT
router-id 10.16.220.1
area 0 sham-link 10.1.1.2 10.1.1.1 cost 2
redistribute connected subnets
redistribute bgp 100 metric 10 subnets
network 10.16.220.0 0.0.0.3 area 0
!
!
router bgp 100
!
address-family ipv4 vrf EX-SPIRIT
network 10.1.1.2 mask 255.255.255.255

network 10.16.220.0 mask 255.255.255.252
redistribute ospf 2200 metric 10 match internal external 1 external 2
exit-address-family
!
end

============PE2================

vrf definition EX-SPIRIT
description St James St
rd 100:2200
!
address-family ipv4
route-target export 100:2200
route-target import 100:2200
exit-address-family
!
!

!
interface GigabitEthernet0/0/0.2200
encapsulation dot1Q 2200
vrf forwarding EX-SPIRIT
ip address 10.16.220.13 255.255.255.252

!
interface Loopback2200
vrf forwarding EX-SPIRIT
ip address 10.1.1.1 255.255.255.255
!
router ospf 2200 vrf EX-SPIRIT
router-id 10.16.220.13
area 0 sham-link 10.1.1.1 10.1.1.2 cost 2
redistribute connected subnets
redistribute bgp 100 metric 10 subnets
network 10.16.220.12 0.0.0.3 area 0
!
!
router bgp 100
!
address-family ipv4 vrf EX-SPIRIT
network 10.1.1.1 mask 255.255.255.255

network 10.16.220.12 mask 255.255.255.252
redistribute ospf 2200 metric 10 match internal external 1 external 2
exit-address-family
!
end

[pigallo]

hello@OwenTaylor ,

you're actually advertising loopbacks into ospf VRF PID (redistribute connected) which should be avoided in your case.
The issue is that if you have a backup L2 link among the sites, you risk to prefer those addresses through the backup link instead. You can exclude those addresses by using a route-map on both PEs.

Regards,

---

@OwenTaylor wrote:

The issue is that the routes for all interfaces are learning via the L2 backdoor links, how do i over come that.
==============PE1-============
vrf definition EX-SPIRIT
description London Ave Link1
rd 100:2200
!
address-family ipv4
route-target export 100:2200
route-target import 100:2200
exit-address-family
!
!

!
interface GigabitEthernet0/0/0.2200
encapsulation dot1Q 2200
vrf forwarding EX-SPIRIT
ip address 10.16.220.1 255.255.255.252

!
interface Loopback2200
vrf forwarding EX-SPIRIT
ip address 10.1.1.2 255.255.255.255
!
router ospf 2200 vrf EX-SPIRIT
router-id 10.16.220.1
area 0 sham-link 10.1.1.2 10.1.1.1 cost 2
redistribute connected subnets
redistribute bgp 100 metric 10 subnets
network 10.16.220.0 0.0.0.3 area 0
!
!
router bgp 100
!
address-family ipv4 vrf EX-SPIRIT
network 10.1.1.2 mask 255.255.255.255

network 10.16.220.0 mask 255.255.255.252
redistribute ospf 2200 metric 10 match internal external 1 external 2
exit-address-family
!
end

============PE2================

vrf definition EX-SPIRIT
description St James St
rd 100:2200
!
address-family ipv4
route-target export 100:2200
route-target import 100:2200
exit-address-family
!
!

!
interface GigabitEthernet0/0/0.2200
encapsulation dot1Q 2200
vrf forwarding EX-SPIRIT
ip address 10.16.220.13 255.255.255.252

!
interface Loopback2200
vrf forwarding EX-SPIRIT
ip address 10.1.1.1 255.255.255.255
!
router ospf 2200 vrf EX-SPIRIT
router-id 10.16.220.13
area 0 sham-link 10.1.1.1 10.1.1.2 cost 2
redistribute connected subnets
redistribute bgp 100 metric 10 subnets
network 10.16.220.12 0.0.0.3 area 0
!
!
router bgp 100
!
address-family ipv4 vrf EX-SPIRIT
network 10.1.1.1 mask 255.255.255.255

network 10.16.220.12 mask 255.255.255.252
redistribute ospf 2200 metric 10 match internal external 1 external 2
exit-address-family
!
end

---

[OwenTaylor]

Thank you, that worked, the shamlink is now up and stable, however i expected the traffic to start traversing the MPLS link but for some reason it is not , all routes are still seeing the L2 link as a preferred path and not the MLS shamlink, what am i missing here?

[Patrick.Williams · Accepted solution]

Configurations on both PE should be as seen below.

router ospf 2200 vrf EX-SPIRIT
router-id 10.16.220.13
area 0 sham-link 10.1.1.1 10.1.1.2 cost 2
redistribute bgp 100 metric 10 subnets
network 10.16.220.12 0.0.0.3 area 0

router ospf 2200 vrf EX-SPIRIT
router-id 10.16.220.1
area 0 sham-link 10.1.1.2 10.1.1.1 cost 2
redistribute bgp 100 metric 10 subnets
network 10.16.220.0 0.0.0.3 area 0

As stated by pigallo, as a standard part of configuring sham-links you have to ensure that the /32 Loopback address  are not apart of the ospf process, once the changes are made you should run the command "show ip route vrf  EX-SPIRIT"

The prefixes for the /32 should be listed as BGP and not OSPF.

You can additionally use the " show ip ospf sham-links" command to verify that the sessions are established. the state will show up as "State POINT_TO_POINT"   or "show ip ospf neigh" and additional neighbor  should be listed,

Example Output

192.168.1.1  0 FULL/ - - 10.99.2.  OSPF_SL0

For optimal routing ensure that the cost values are correctly imputed on the the interfaces of the CE devices.