In this article, you will read about when the Open Shortest Path First (OSPF) protocol inside a virtual routing and forwarding instance (VRF) stops redistributing a specific route, how to confirm the symptoms, and the workaround.
+-----------------------+ | | | receive-static | | | area 0 | | | | +------------------------+----------+------------------------+ | | VRF1 | | | | | | +-----+-----+----+------+ | area 31 NSSA | | | | | | +-----+----+ | VRF2 | | | +----------+
We have two VRF instances connected on this topology:
VRF2 is on area 31 (NSSA) and has VRF1 as neighbor.
VRF1 is an area border router (ABR), connected to area 0 and area 31. VRF1 connects to the logical-system "receive-static" and forms an adjacency in area 0.
From VRF2, we redistribute a static route pointing to discard. Ideally, VRF2 should redistribute this route into the area as Type 7, which VRF1 should then redistribute to area 0 as type 5.
user@lab_1# show routing-instances VRF1 instance-type vrf; interface ge-0/2/0.0; interface ge-0/2/1.0; route-distinguisher 64512:533; vrf-import VRF1-import; vrf-export VRF1-export; vrf-table-label; protocols { ospf { area 0.0.0.31 { nssa { default-lsa default-metric 5; } interface ge-0/2/0.0; } area 0.0.0.0 { interface ge-0/2/1.0; } } } user@lab_1# show routing-instances VRF2 instance-type vrf; interface ge-0/3/0.0; route-distinguisher 172.16.1.2:10; vrf-import VRF2-import; vrf-export VRF2-export; routing-options { static { route 172.16.100.100/29 discard; } } protocols { ospf { export export-static; area 0.0.0.31 { nssa { default-lsa default-metric 5; } interface ge-0/3/0.0; } } } user@lab_1# show logical-systems receive-static interfaces { ge-0/3/1 { unit 0 { family inet { address 172.16.1.6/30; } } } } protocols { ospf { area 0.0.0.0 { interface ge-0/3/1.0; } } }
When you check the database from VRF2, you see that the static route has been exported as type 7.
user@lab_1_1# run show ospf database instance VRF2 OSPF database, Area 0.0.0.31 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.16.1.1 172.16.1.1 0x80000008 471 0x20 0x1703 36 Router *172.16.1.2 172.16.1.2 0x80000009 470 0x20 0x1303 36 Network *172.16.1.2 172.16.1.2 0x80000007 470 0x20 0xa184 32 Summary 172.16.1.4 172.16.1.1 0x80000003 484 0x20 0x3103 28 NSSA 0.0.0.0 172.16.1.1 0x80000003 484 0x20 0x8f98 36 NSSA *0.0.0.0 172.16.1.2 0x80000003 470 0x20 0x899d 36 NSSA *172.16.100.100 172.16.1.2 0x80000003 470 0x28 0x8333 36 <<<<<<<<<
Now when you check the database on VRF1, you should see the 172.16.100.100 route.
user@lab_1_1> show ospf database instance VRF1 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.16.1.1 172.16.1.1 0x8000000b 1447 0x22 0xe92e 36 Router *172.16.1.2 172.16.1.2 0x80000013 233 0x22 0xe029 36 Network *172.16.1.2 172.16.1.2 0x8000000d 2633 0x22 0x77a6 32 Summary *172.16.2.0 172.16.1.2 0x8000000f 1433 0x22 0xf82d 28 <<<<< Not seen on area 0 as type 5 OSPF database, Area 0.0.0.31 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.2 172.16.1.2 0x80000006 2033 0x20 0x47cc 36 Router 172.16.2.2 172.16.2.2 0x80000006 2434 0x20 0x19f3 36 Network 172.16.2.2 172.16.2.2 0x80000004 1434 0x20 0x918d 32 Summary *172.16.1.0 172.16.1.2 0x80000005 833 0x20 0x4fe5 28 NSSA 172.16.100.100 172.16.2.2 0x80000005 434 0x28 0x8b23 36 <<<<< It is indeed being advertised by the peer as NSSA.
A VRF is mainly used for Multiprotocol Label Switching (MPLS) L3VPN deployments. We mostly use it to deploy OSPF between customer edge (CE)-provider edge (PE) routers. In this case, we are using the VRF instance to redistribute routes between tables.
By default, OSPF acts as an ABR when configured in VRF instances. Because the routing-instance VRF1 detects VRF2 as an ABR and injects the route into the area, it does not redistribute the route 172.16.100.100 to area 0 to avoid a routing loop. If we check the router link-state advertisement (LSA) received on VRF1 from VRF2, we can see the bits field indicates 0x3:
[edit] user@lab_1# run show ospf database instance VRF1 lsa-id 172.16.1.2 detail OSPF database, Area 0.0.0.31 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.16.1.2 172.16.1.2 0x80000004 1881 0x20 0x1dfd 36 bits 0x3 , link count 1 id 172.16.1.2, data 172.16.1.2, Type Transit (2) Topology count: 0, Default metric: 1 Topology default (ID 0) Type: Transit, Node ID: 172.16.1.2 Metric: 1, Bidirectional Network 172.16.1.2 172.16.1.2 0x80000002 2567 0x20 0xab7f 32 mask 255.255.255.252 attached router 172.16.1.2 attached router 172.16.1.1 Topology default (ID 0) Type: Transit, Node ID: 172.16.1.1 Metric: 0, Bidirectional Type: Transit, Node ID: 172.16.1.2 Metric: 0, Bidirectional
Bit 0x1 = area border router (ABR) and bit 0x2 = autonomous system boundary router (ASBR), so bit 0x3 makes it an ASBR and an ABR. ASBR because it is importing routes from another protocol (static) and ABR as explained Area Border Routers.
Routing devices that belong to more than one area and connect one or more OSPF areas to the backbone area are called area border routers (ABRs). At least one interface is within the backbone while another interface is in another area. ABRs also maintain a separate topological database for each area to which they are connected.
But the configuration only shows area 31 configured here, so there is no way routing-instance VRF2 could be an ABR:
user@lab_1_1# show routing-instances VRF2 instance-type vrf; interface ge-0/3/0.0; route-distinguisher 172.16.1.2:10; vrf-import VRF2-import; vrf-export VRF2-export; routing-options { static { route 172.16.100.100/29 discard; } } protocols { ospf { export export-static; area 0.0.0.31 { nssa { default-lsa default-metric 5; } interface ge-0/3/0.0; } } }
Solution to the Problem
The solution to this problem is to configure the routing-instance as a virtual router. The main difference between a VRF instance and a virtual router is that VRF instances are used to work with MPLS capabilities, whereas virtual routers are used to create a separate routing-table.
[edit] user@lab_1# show routing-instances | display set set routing-instances VRF1 instance-type virtual-router set routing-instances VRF2 instance-type virtual-router [edit] user@lab_1# run show ospf database instance VRF1 lsa-id 172.16.1.2 detail OSPF database, Area 0.0.0.31 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.16.1.2 172.16.1.2 0x80000002 2 0x20 0xae78 36 bits 0x2 , link count 1 id 172.16.1.0, data 255.255.255.252, Type Stub (3) Topology count: 0, Default metric: 1
With the routing instances configured as "virtual-router," the OSPF database shows the bits capabilities from routing-instance static as an ASBR. This will now install and flood the 172.16.100.100 IP address to area 0:
user@lab_1# run show ospf database instance VRF1 area 0 OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router *172.16.1.1 172.16.1.1 0x80000015 15 0x22 0x3fc3 36 Router 172.16.1.6 172.16.1.6 0x80000014 1224 0x22 0xf506 36 Network 172.16.1.6 172.16.1.6 0x80000004 1224 0x22 0x71a9 32 Summary *172.16.1.0 172.16.1.1 0x80000011 1186 0x22 0x1f09 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern *172.16.100.100 172.16.1.1 0x80000001 1181 0x22 0x4bd 36 <<<<<<<<<<<<<< type 5 route [edit] user@lab_1# run show ospf database logical-system receive-static OSPF database, Area 0.0.0.0 Type ID Adv Rtr Seq Age Opt Cksum Len Router 172.16.1.1 172.16.1.1 0x80000015 27 0x22 0x3fc3 36 Router *172.16.1.6 172.16.1.6 0x80000014 1234 0x22 0xf506 36 Network *172.16.1.6 172.16.1.6 0x80000004 1234 0x22 0x71a9 32 Summary 172.16.1.0 172.16.1.1 0x80000011 1198 0x22 0x1f09 28 OSPF AS SCOPE link state database Type ID Adv Rtr Seq Age Opt Cksum Len Extern 172.16.100.100 172.16.1.1 0x80000001 1193 0x22 0x4bd 36 <<<<<<< now received as type 5
2022/10/19:Changed IP address to be compliant with RFC block