cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
17608
Views
15
Helpful
10
Replies

Route exchange between VRF's and OSPF processes

hmdavies
Level 1
Level 1

I wish to advertise routes between MPLS VRF's - I do not want to add route leaking on the WAN CE.

I have 2 VRF's terminating on 1 x CE router, the CE the connects to another router with 2 x OSPF processes (1 each for each VRF). The 2nd router then redistributed between the 2 OSPF process.

 

CE config below;

 

router ospf 100 vrf VRFA
 router-id 192.168.1.17
 redistribute bgp 64512 metric 1 subnets route-map bgp-ospf100
 network 192.168.1.16 0.0.0.3 area 0
!
router ospf 200 vrf VRFB
 router-id 192.168.2.21
 redistribute bgp 64512 metric 1 subnets route-map bgp-ospf200
 network 192.168.2.20 0.0.0.3 area 0
!
router bgp 64512
 bgp router-id 1.1.1.1
 bgp log-neighbor-changes
 timers bgp 3 9
 !
 address-family ipv4 vrf VRFA
  bgp router-id 192.168.1.9
  redistribute ospf 100 metric 1
  neighbor 192.168.1.9 remote-as 1000
  neighbor 192.168.1.9 activate
 exit-address-family
 !
 address-family ipv4 vrf VRFB
  bgp router-id 192.168.1.13
  redistribute ospf 200 metric 1
  neighbor 192.168.1.9 remote-as 1000
  neighbor 192.168.1.9 activate
 exit-address-family
!
ip prefix-list bgp-ospf100 seq 5 permit 172.16.1.1/32
!
ip prefix-list bgp-ospf200 seq 5 permit 172.16.1.2/32
!
route-map bgp-ospf200 permit 10
 match ip address prefix-list bgp-ospf200
!
route-map bgp-ospf100 permit 10
 match ip address prefix-list bgp-ospf100
!

The CE router shows prefixes from Router 2 in the ospf database but does not show these as IP routes - for example

show ip route vrf VRFA would show routes leant from the MPLS VRF network but not those learnt via OSPF

 

 

 

1 Accepted Solution

Accepted Solutions

Well that was fun :-)

Sorry it took a while but I hit a few snags along the way.

I replicated your setup in a lab and saw exactly the same issue.

The simple answer is you need to add this to each of your OSPF vrf configurations on your CE device -

"capability vrf-lite"

I can't really take much credit for that as I had to dig around CSC to find this post where it is explained by Peter as to why you need it -

https://supportforums.cisco.com/discussion/11178396/ospf-routing-bit-lsa

please read the post before you decide whether or not to apply the command because you need to understand the implications of using it.

Jon

View solution in original post

10 Replies 10

Jon Marshall
Hall of Fame
Hall of Fame

If you redistribute between OSPF then the redistributed routes will be external routes.

OSPF external routes are not redistributed into BGP unless you explicitly configure it ie. your redistribute ospf command under the BGP configuration will only match intra and inter area routes.

So can you modify the command under your BGP configuration to be -

redistribute ospf 200  match internal external 1 external 2 metric 1

Jon

thanks for your response - I have added the extra keywords but no improvement. output below

DC-CE#sh ip ro vrf VFRB os


      172.16.0.0/32 is subnetted, 2 subnets
O        172.16.1.3 [110/2] via 192.168.1.22, 00:00:53, FastEthernet2/0
      192.168.1.0/24 is variably subnetted, 5 subnets, 2 masks
O E2     192.168.1.16/30 [110/1] via 192.168.1.22, 00:01:51, FastEthernet2/0


DC-CE#sh ip ro vrf VRFA os


      172.16.0.0/32 is subnetted, 2 subnets
O E2     172.16.1.3 [110/1] via 192.168.1.18, 00:01:07, FastEthernet1/1
      192.168.1.0/24 is variably subnetted, 5 subnets, 2 masks
O E2     192.168.1.20/30 [110/1] via 192.168.1.18, 00:02:09, FastEthernet1/1
DC-CE#

 

the only routes seen in OSPF are the point-point links between DC-CE & Router2 and Router2's loopback. Although routes to 172.16.1.1 & 172.16.1.2 appear in the OSPF database

DC-CE#sh ip osp data

            OSPF Router with ID (192.168.2.21) (Process ID 200)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
192.168.1.22    192.168.1.22    376         0x80000004 0x00F2DB 3
192.168.2.21    192.168.2.21    511         0x80000001 0x001192 2

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
172.16.1.1      192.168.1.22    434         0x80000001 0x00FFA6 3489725440
172.16.1.2      192.168.2.21    509         0x80000002 0x006BB8 3489725440
192.168.1.16    192.168.1.22    433         0x80000001 0x002299 0

            OSPF Router with ID (192.168.1.17) (Process ID 100)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.16.1.3      172.16.1.3      449         0x80000002 0x0030FE 2
192.168.1.17    192.168.1.17    609         0x80000002 0x00C0B3 2

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
172.16.1.1      192.168.1.17    674         0x80000001 0x009694 3489725440
172.16.1.2      172.16.1.3      438         0x80000001 0x00E183 3489725440
172.16.1.3      172.16.1.3      376         0x80000001 0x00CE63 0
192.168.1.20    172.16.1.3      438         0x80000001 0x00E591 0
DC-CE#

 

 

Okay I'm confused now.

Looking at your CE configuration 172.16.1.1 and 172.16.1.2 are being received by BGP and then redistributed into OSPF.

If they are received by BGP they will have an AD of 20.

You then redistribute these into OSPF and then redistribute between OSPF on your internal router.

When they get back to the CE device from your internal router they are still OSPF routes so they have an AD of 110.

Which means the CE device will choose the BGP routes because of the lower AD so the OSPF routes are never installed in the IP routing table.

So they can never be redistributed back into BGP.

Jon

The CE will receive 172.16.1.1 via VRFA, this is then redistributed into OSPF Process 100. As the CE has an OSPF peering with Router2 within Process 100 this route is exchanged with Router2.

Router 2 will then redistribute the route from OSPF100 to OSPF200 and pass the route back to the CE via OSFP process 200. OSPF 200 is within VRFB.

 

The CE should the redistibute the route from OSPF 200 to BGP in VRFB and advertise to VRFB

Yes, sorry,  I should have thought about that a bit more before I posted a response.

I will try and lab this up and see if I get the same results and let you know.

Can you post the full configuration of the CE device ?

Jon

CE and Router 2 configs attached, thanks again

Well that was fun :-)

Sorry it took a while but I hit a few snags along the way.

I replicated your setup in a lab and saw exactly the same issue.

The simple answer is you need to add this to each of your OSPF vrf configurations on your CE device -

"capability vrf-lite"

I can't really take much credit for that as I had to dig around CSC to find this post where it is explained by Peter as to why you need it -

https://supportforums.cisco.com/discussion/11178396/ospf-routing-bit-lsa

please read the post before you decide whether or not to apply the command because you need to understand the implications of using it.

Jon

many thanks for your help

DC-CE#sh ip ro vrf VFRB os


      172.16.0.0/32 is subnetted, 2 subnets
O        172.16.1.3 [110/2] via 192.168.1.22, 00:00:53, FastEthernet2/0
      192.168.1.0/24 is variably subnetted, 5 subnets, 2 masks
O E2     192.168.1.16/30 [110/1] via 192.168.1.22, 00:01:51, FastEthernet2/0


DC-CE#sh ip ro vrf VRFA os


      172.16.0.0/32 is subnetted, 2 subnets
O E2     172.16.1.3 [110/1] via 192.168.1.18, 00:01:07, FastEthernet1/1
      192.168.1.0/24 is variably subnetted, 5 subnets, 2 masks
O E2     192.168.1.20/30 [110/1] via 192.168.1.18, 00:02:09, FastEthernet1/1
DC-CE#

 

routes the only seen in OSPF are the point-point links between DC-CE & Router2 and Router2's loopback. Although routes to 172.16.1.1 & 172.16.1.2 appear in the OSPF database

DC-CE#sh ip osp data

            OSPF Router with ID (192.168.2.21) (Process ID 200)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
192.168.1.22    192.168.1.22    376         0x80000004 0x00F2DB 3
192.168.2.21    192.168.2.21    511         0x80000001 0x001192 2

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
172.16.1.1      192.168.1.22    434         0x80000001 0x00FFA6 3489725440
172.16.1.2      192.168.2.21    509         0x80000002 0x006BB8 3489725440
192.168.1.16    192.168.1.22    433         0x80000001 0x002299 0

            OSPF Router with ID (192.168.1.17) (Process ID 100)

                Router Link States (Area 0)

Link ID         ADV Router      Age         Seq#       Checksum Link count
172.16.1.3      172.16.1.3      449         0x80000002 0x0030FE 2
192.168.1.17    192.168.1.17    609         0x80000002 0x00C0B3 2

                Type-5 AS External Link States

Link ID         ADV Router      Age         Seq#       Checksum Tag
172.16.1.1      192.168.1.17    674         0x80000001 0x009694 3489725440
172.16.1.2      172.16.1.3      438         0x80000001 0x00E183 3489725440
172.16.1.3      172.16.1.3      376         0x80000001 0x00CE63 0
192.168.1.20    172.16.1.3      438         0x80000001 0x00E591 0
DC-CE#

 

====================

172.16.1.1 & 172.16.1.2 in your output showing in the OSPF database but not in the routing table why? Because they are assigned a Tag "3489725440" in the last you can see. which is the BGP AS 64512 and because these prefixes are tagged, no SPF will run on it and will then not be forwarded from database to the routing table.

This default behaviour happens when we do redistribution from BGP to OSPF. A tag added to them to avoid the Loop. As you are redistributing at R2 so these routes are going back to the CE and CE blocks them by not running SPF on these routes in the database. Ultimately these prefixes are not showing in the routing table.

If by some reason as per your scenario you want these routes to be shown in the routing table and wants to bypass the default behaviour of assigning checks during BGP to OSPF redistribution, YOU HAVE TO ENABLE THE VRF-LITE CAPABILITY ON YOUR CE. Go to the Routing process at CE and type the command as JON mentioned.

Other way is the filter out the Tag somehow.

One more way is to inject the routes into OSPF database as Type-1 LSA not Type-5 LSA. ...... 

 

 

ravishukla12911
Level 1
Level 1

Mu issue resolved with this example