Route leaking between 2 VRFs using OSPF

[alexb931]

hi all, 

I'm wondering if its possible to route leak between 2 OSPF Instances running on different VRFs without using the GRT. 

I've not found much around asides from route leaking using a VRF and the global routing. A workaround would be from an OSPF VRF to a BGP VRF if possible.

Thank you,

Thank you

[paul driver]

Hello

Are you using l3VPN or VRF Lite , if the latter you have two options:

import-maps with route-targets
static routing

Can you confirm if this will be between two vrf instances or just the one instance into the global rib.

Please post the rtr configurations if applicable

[alexb931]

Hi Paul,

This would be VRF Lite. I've tried to do a static route with the next hop being the same device but an interface inside the opposite VRF. You'll see some afwful Route target config in there aswell where i was trying to guess my way through it (Didn't work!). If static routes are simpler that would be my preference as I'm only trying to leak 1 route each way. 

172.23.77.25 is a host route learned from OSPF on an adjacent device inside TP

LEG-CORE-BAS# show run
Building configuration...

Current configuration : 2667 bytes
!
! Last configuration change at 22:09:33 UTC Wed Jun 19 2019
!
version 15.2
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname LEG-CORE-BAS
!
boot-start-marker
boot-end-marker
!
!
!
no aaa new-model
ip cef
!
ip vrf INNER
rd 64605:1
import ipv4 unicast map TP-INNER
route-target export 61000:1
route-target import 61000:1
route-target import 33:33
!
ip vrf THIRDPARTY
rd 61000:1
export map TP-INNER
export ipv4 unicast map TP-INNER
route-target export 61000:1
!
!
!
!
!
!
no ip domain lookup
no ipv6 cef
!
!
multilink bundle-name authenticated
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface Loopback1
ip vrf forwarding THIRDPARTY
ip address 172.23.77.1 255.255.255.255
!
interface Loopback4
ip vrf forwarding INNER
ip address 10.39.0.1 255.255.0.0
!
interface Tunnel1
ip vrf forwarding THIRDPARTY
no ip address
!
interface FastEthernet0/0
ip vrf forwarding THIRDPARTY
ip address 172.23.77.10 255.255.255.248
duplex full
!
interface FastEthernet1/0
no ip address
shutdown
duplex full
!
interface Ethernet2/0
ip vrf forwarding INNER
ip address 10.174.64.5 255.255.255.254
duplex full
!
interface Ethernet2/1
no ip address
shutdown
duplex full
!
interface Ethernet2/2
no ip address
shutdown
duplex full
!
interface Ethernet2/3
no ip address
shutdown
duplex full
!
interface Ethernet2/4
no ip address
shutdown
duplex full
!
interface Ethernet2/5
no ip address
shutdown
duplex full
!
interface Ethernet2/6
no ip address
shutdown
duplex full
!
interface Ethernet2/7
no ip address
shutdown
duplex full
!
router ospf 1 vrf THIRDPARTY
network 172.23.77.1 0.0.0.0 area 0
network 172.23.77.9 0.0.0.0 area 0
network 172.23.77.8 0.0.0.7 area 0
network 172.23.77.17 0.0.0.0 area 0
!
router ospf 2 vrf INNER
network 10.39.0.0 0.0.255.255 area 0
!
router bgp 64605
bgp router-id 10.174.64.5
bgp log-neighbor-changes
!
address-family ipv4 vrf INNER
network 10.39.0.0 mask 255.255.0.0
network 10.174.64.5
network 10.174.64.5 mask 255.255.255.255
network 172.23.77.1 mask 255.255.255.255
neighbor 10.174.64.4 remote-as 39173
neighbor 10.174.64.4 activate
exit-address-family
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip route 172.23.77.25 255.255.255.255 172.23.77.10
ip route vrf INNER 172.23.77.25 255.255.255.255 172.23.77.10
!
access-list 1 permit 172.23.77.25
access-list 50 permit 0.0.0.0
access-list 50 permit 172.23.77.25
access-list 50 permit any
!
route-map TP-INNER permit 10
match ip address 1
set extcommunity rt 33:33 additive
!
!
!
control-plane
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
!
end

LEG-CORE-BAS#

[Patryk Nieborak]

Hello,

Even though this is old topic, I decided to post the solution since I've just worked myself out of the same problem. Based on the logic for EIGRP Inter-VRF leaking:

1) Configure VRFs and OSPF processes.

---

vrf definition LAN-SERVICE
rd 3:3
address-family ipv4
route-target export 371:341
route-target import 371:340

vrf definition MPLS-FVRF
rd 2:2
address-family ipv4
route-target export 371:340
route-target import 371:341

router ospf 66 vrf MPLS-FVRF
router-id 4.4.4.4

router ospf 77 vrf LAN-SERVICE
router-id 4.4.4.4

int gi1
vrf forwarding MPLS-FVRF
ip ospf 66 area 0

int gi4
vrf forwarding LAN-SERVICE
ip ospf 77 area 0

2) Configure BGP, redistribute from OSPFs to BGP.

router bgp 64512
address-family ipv4 vrf LAN-SERVICE
redistribute ospf 77 match internal external 1 external 2
address-family ipv4 vrf MPLS-FVRF
redistribute ospf 66 match internal external 1 external 2

3) Configure redistribution back from BGP towards OSPF processes.

router ospf 66 vrf MPLS-FVRF
redistribute bgp 64512
router ospf 77 vrf LAN-SERVICE
redistribute bgp 64512

4) Now, in my example I wanted to pass routes learnt in the OSPF process running in LAN to OSPF process running towards MPLS PE that is also using VRFs (VRFs are local to the router). Since on CE I was seeing them properly imported into MPLS-FVRF routing table (checked via sh ip route vrf MPLS-FVRF, you should see something like below), I started verification on MPLS PE.

B 10.2.3.224/28
[20/2] via 10.1.1.30 (LAN-SERVICE), 01:06:51, GigabitEthernet4

Now apparently MPLS PE received Type-5 LSAs, but decided not to install information from them in its routing table:

LS age: 1637
Options: (No TOS-capability, DC, Downward)
LS Type: AS External Link
Link State ID: 10.1.1.28 (External Network Number )
Advertising Router: 4.4.4.4
LS Seq Number: 80000025
Checksum: 0x3265
Length: 36
Network Mask: /30
Metric Type: 1 (Comparable directly to link state metric)
MTID: 0
Metric: 500
Forward Address: 0.0.0.0
External Route Tag: 3489725440

I noticed this external route tag that was already set by CE. I needed to configure MPLS PE with capability vrf-lite under OSPF process, so it can install these prefixes. OSPF Inter-VRF leaking using BGP tables triggers relation between OSPF-BGP in regards to MPLS Superbackbone (RFC 4577 talks in detail about that) and seems to be causing that, at least in my case.

CE#sh bgp * all detail | sec 10.5.3.224
BGP routing table entry for 2:2:10.5.3.224/28, version 910
Paths: (1 available, best #1, table MPLS-FVRF)
Not advertised to any peer
Refresh Epoch 1
Local, imported path from 3:3:10.5.3.224/28 (LAN-SERVICE)
10.1.1.30 (via vrf LAN-SERVICE) (via LAN-SERVICE) from 0.0.0.0 (172.16.0.6)
Origin incomplete, metric 2, localpref 100, weight 32768, valid, external, best
Extended Community: RT:371:341 OSPF DOMAIN ID:0x0005:0x0000004D0200
OSPF RT:0.0.0.0:2:0 OSPF ROUTER ID:4.4.4.4:0
rx pathid: 0, tx pathid: 0x0

See also:
https://community.cisco.com/t5/routing/ospf-routing-bit-in-lsa/td-p/1724287

https://community.cisco.com/t5/other-service-provider-subjects/isr-4331-with-ospf-troubles-in-vrf-lite/td-p/2634023

[Patryk Nieborak]

Just to add to my previous message, I'm running also IPv6 in those VRFs and MPLS (basically my whole lab is fully IPv4/IPv6). For OSPFv3, LSAs generated by CE after VRF-leaking (I used same logic as for IPv4 described above) had DN-bit set, hence they were also ignored by MPLS PE. I needed to configure "capability vrf-lite", but this time on CE to clear DN-bit upon Type 5 LSA generation. See this link for more info: https://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/200062-Configure-OSPFv3-as-PE-CE-Protocol-with.html