Hi Thot,

Yes, it is exactly what I want to do : establish an OSPF adjacency between to Interfaces belonging to the same router but to different VRFs. If is not supported, do you know why ? I tested with RIP and it works perfectly

Thank you

Yves

NB : Your right, there is a typo in the configuration (import statement). Here is an updated version :

ip cef

!

ip vrf RT3

rd 7500:3

route-target export 7500:3

route-target import 7500:3

!

ip vrf RT4

rd 7500:4

route-target export 7500:4

route-target import 7500:4

!

interface Loopback3

ip vrf forwarding RT3

ip address 3.3.3.3 255.255.255.255

!

interface Loopback4

ip vrf forwarding RT4

ip address 4.4.4.4 255.255.255.255

!

interface FastEthernet0/0

description *** RT3 VRF Interface ***

ip vrf forwarding RT3

ip address 192.168.1.3 255.255.255.0

duplex auto

speed auto

!

interface FastEthernet0/1

description *** RT4 VRF Interface ***

ip vrf forwarding RT4

ip address 192.168.1.4 255.255.255.0

duplex auto

speed auto

!

router ospf 3 vrf RT3

log-adjacency-changes

capability vrf-lite

redistribute connected subnets

network 192.168.1.3 0.0.0.0 area 0

!

router ospf 4 vrf RT4

log-adjacency-changes

capability vrf-lite

redistribute connected subnets

network 192.168.1.4 0.0.0.0 area 0

!

yves,

I'd apologize you. I missed understanding VRF-Lite on some points.OSPF can from adjacency between VRFs. I tested your lab. Ahh,It worked like a charm. My IOS is 12.4(7h). I'm not sure that this is an IOS problem. I'm waiting for my idol,HAROLD RITTER to shed some light on this. ;-)

Cheers,

Thot

Thot,

Thanks for raising the issue. I found the bugid that causes the issue I mentioned in my previous post.

BugID: CSCdu28706

Description:

ARP rejects requests from interfaces in different vrfs

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCdu28706

This bug is fixed in 12.4(1), which explains why you are not seeing the same issue with 12.4(7).

Regards,

Yves,

I have seen this issue with certain IOS versions in the past. The issue is most probably that the dynamic ARP doesn't behave properly in the VRF context, which would explained why the ospf adjacency gets stuck in EXSTART, as the DB description messages are exchanged using unicast addresses. This would also explain why it worked with RIP, as it propagates updates using either the broadcast address (RIP) or the multicast address (RIPv2).

A workaround would be to configured static ARP entries in each VRF as follow:

arp vrf RT3 192.168.1.4 ARPA

arp vrf RT4 192.168.1.3 ARPA

Regards,

Harold,

Nice explanation! as always.

Thanks

Thot

Thanks Thot. It is always a pleasure.

Hi Thot and Harold,

Your are both really great ! Within a few hours, from the other side of the planet, you explained and solved my problem ! I tested the static ARP entries method and it works fine now. I really want to thank you for your valuable contribution.

My test lab was on a 2651XM platform, but the real customer environment will be on a Catalyst 6500 running native IOS version 12.2.(33)SXF. I will see if the bug is fixed or not ;-)

Thanks again a lot !

Yves

Yves,

You are very welcome.

I am not sure if you meant 12.2(18)SXF or 12.2(33)SXH. The issue is definitely fixed in both versions anyway.

Regards,

I know this is a old thread, I faced same problem when implement some work.

I place two ASA 5550s inside outside interface  between two same  nexus 9300 ileaf switches , and asa run in transparent mode.

I have many vrfs running on nexus 9300(because this is vxlan enviriment).  I want to implement vrf ospf neighbor across transparent vlan on asa, there will be 200 vrf ospf neighbors across asa between same  nexus 9300 on different vrf 

 does I  need create loopback interface for each vrf on nexus 93 for ospf router id？

thank you

Jeremy