Article Detail

Description

This article explains how to install LSA type 3, LSA type 5 and LSA type 7 routes in the routing instance type, virtual routing and forwarding (VRF) routing table in a scenario where these LSAs are learned over a non-zero connected area.

Symptoms

Consider the following scenario:

R1-PE (VRF) --- Link in OSPF Area 45 --- R2-CE1 --- Link in OSPF Area 0 --- R3-CE2

lab@R1-PE> show configuration routing-instances TEST
instance-type vrf;
interface ae2.0;
route-distinguisher 4.4.4.4:4;
vrf-target target:1:1;
vrf-table-label;
protocols {
    ospf {
        area 0.0.0.45 {
            interface ae2.0 {
                interface-type p2p;
            }
        }
    }
}

lab@R2-CE1> show configuration protocols ospf   
area 0.0.0.45 {
    interface ae2.0 {
        interface-type p2p;
    }
}
area 0.0.0.0 {
    interface ge-0/0/5.0 {
        interface-type p2p;
    }
}

lab@R3-CE2> show configuration protocols ospf  
export DIRECT_TO_OSPF;
area 0.0.0.0 {
    interface ge-0/0/1.0 {
        interface-type p2p;
    }
}

Router R3-CE2, which is a backbone area and also ASBR router is advertising external routes 192.168.1.0/24, 192.168.2.0/24 and 192.168.3.0/24. Router R2-CE1 is an ABR router and it is advertising the summary route 172.27.0.56/30 towards router R1-PE.

lab@R1-PE> show ospf database instance TEST   
    OSPF database, Area 0.0.0.45
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   2.2.2.2          2.2.2.2          0x80000002    23  0x22 0x7706  48
Router  *172.27.0.21      172.27.0.21      0x80000002    22  0x22 0x9b0e  48
Summary  172.27.0.56      2.2.2.2          0x80000002    39  0x22 0x72f   28
ASBRSum  3.3.3.3          2.2.2.2          0x80000001     5  0x22 0xbe68  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   192.168.1.0      3.3.3.3          0x80000001   326  0x22 0xe952  36
Extern   192.168.2.0      3.3.3.3          0x80000001   326  0x22 0xde5c  36
Extern   192.168.3.0      3.3.3.3          0x80000001   326  0x22 0xd366  36
 
lab@R1-PE> show route protocol ospf table TEST.inet.0
TEST.inet.0: 3 destinations, 3 routes (3 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
224.0.0.5/32       *[OSPF/10] 00:00:53, metric 1
                      MultiRecv

All routes are in the Open Shortest Path First (OSPF) database of routing instance TEST, but none of the External and Summary routes are installed in the routing table.

Solution

If an OSPF process is performed in a routing instance type VRF, then the router automatically and unconditionally considers itself to be an ABR. The router believes to be connected to a so-called MPLS backbone (even though there may be no BGP/MPLS configured on the router at all). This may pose as problems if such a router is actually a part of a network that uses multiple areas.

In this scenario, R2-CE1 is obviously an ABR because it has two links, one in Area 0, the other in Area 45. R1-PE is an internal router in Area 45. However, because R1-PE has the link toward R2-CE1, and OSPF configured over this link in a VRF routing instance, R1-PE considers itself to also be an ABR toward the MPLS backbone.

As a result, router R1-PE, thinking it is an ABR, will not place any networks from Area 0 nor from any other area behind R2-CE1 into its routing table. Based on OSPF rules, an ABR processes only those inter-area routes that have been received over an adjacency in Area 0, and R1-PE has no such adjacency. The end result will be that R1-PE will be unable to talk with any network outside its own Area 45.

In order to suppress the provider edge (PE) specific checks on a router when the OSPF process is associated with the VPN routing and forwarding instance (VRF), it is needed to disable domain-ID under OSPF configuration on PE router.

OSPF checks if the PE router is needed to prevent loops when the PE is performing a mutual redistribution between OSPF and Border Gateway Protocol (BGP) interfaces. In some situations, like in the scenario above, performing PE checks might not be desirable. With the domain-id disable command, the checks can be turned off to allow correct population of the VRF routing table with OSPF routes.

lab@R1-PE> show configuration routing-instances TEST protocols ospf
domain-id disable;
area 0.0.0.45 {
    interface ae2.0 {
        interface-type p2p;
    }
}

lab@R1-PE> show ospf database instance TEST                           
    OSPF database, Area 0.0.0.45
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   2.2.2.2          2.2.2.2          0x80000002   164  0x22 0x7706  48
Router  *172.27.0.21      172.27.0.21      0x80000003    59  0x22 0x9613  48
Summary  172.27.0.56      2.2.2.2          0x80000002   180  0x22 0x72f   28
ASBRSum  3.3.3.3          2.2.2.2          0x80000001   146  0x22 0xbe68  28
    OSPF AS SCOPE link state database
 Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Extern   192.168.1.0      3.3.3.3          0x80000001   467  0x22 0xe952  36
Extern   192.168.2.0      3.3.3.3          0x80000001   467  0x22 0xde5c  36
Extern   192.168.3.0      3.3.3.3          0x80000001   467  0x22 0xd366  36
 
lab@R1-PE> show route protocol ospf table TEST.inet.0   
TEST.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
172.27.0.56/30     *[OSPF/10] 00:01:14, metric 2
                    > to 172.27.0.22 via ae2.0
192.168.1.0/24     *[OSPF/150] 00:01:14, metric 0, tag 0
                    > to 172.27.0.22 via ae2.0
192.168.2.0/24     *[OSPF/150] 00:01:14, metric 0, tag 0
                    > to 172.27.0.22 via ae2.0
192.168.3.0/24     *[OSPF/150] 00:01:14, metric 0, tag 0
                    > to 172.27.0.22 via ae2.0
224.0.0.5/32       *[OSPF/10] 00:03:06, metric 1
                      MultiRecv