01-26-2015 02:18 AM - edited 03-05-2019 12:39 AM
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
Solved! Go to Solution.
01-26-2015 10:36 AM
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
01-26-2015 05:03 AM
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
01-26-2015 05:48 AM
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#
01-26-2015 06:20 AM
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
01-26-2015 06:29 AM
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
01-26-2015 07:46 AM
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
01-26-2015 08:00 AM
01-26-2015 10:36 AM
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
01-28-2015 12:52 AM
many thanks for your help
01-27-2015 12:29 PM
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. ......
05-13-2019 03:26 PM
Mu issue resolved with this example
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide