Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

OSPF on VRF not redistributing routes

0

0

Article ID: KB32058 KB Last Updated: 13 Aug 2017Version: 1.0
Summary:

This article describes the behavior when an OSPF inside a VRF does not redistribute a specific route, how to confirm the symptoms and the workaround. 

Symptoms:

Following is the topology used as case study:

                   +-----------------------+
                   |                       |
                   |     receive-static    |
                   |                       |     area 0
                   |                       |
                   |                       |
+------------------------+----------+------------------------+
                   |     |   VRF1   |      |
                   |     |          |      |
                   +-----+-----+----+------+
                               |                 area 31 NSSA
                               |
                               |
                               |
                               |
                               |
                               |
                         +-----+----+
                         |   VRF2   |
                         |          |
                         +----------+


We have two VRFs connected on this topology: VRF2 is on area 31 (NSSA) and has VRF1 as neighbor. VRF1 is an ABR, connected to area 0 and area 31. VRF1 connects to logical-system "receive-static" and forms an adjacency in area 0. From VRF2 we redistribute a static route pointing to discard. Ideally, VRF2 will redistribute this route into the area as Type 7, which then VRF1 will redistribute to area 0 as type 5 as well. 

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 1.1.1.2:10;
vrf-import VRF2-import;
vrf-export VRF2-export;
routing-options {
    static {
        route 100.100.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 1.1.1.6/30;
            }
        }
    }
}
protocols {
    ospf {
        area 0.0.0.0 {
            interface ge-0/3/1.0;
        }
    }
}


Checking on the database from VRF2 we see the static route being 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   1.1.1.1          1.1.1.1          0x80000008   471  0x20 0x1703  36
Router  *1.1.1.2          1.1.1.2          0x80000009   470  0x20 0x1303  36
Network *1.1.1.2          1.1.1.2          0x80000007   470  0x20 0xa184  32
Summary  1.1.1.4          1.1.1.1          0x80000003   484  0x20 0x3103  28
NSSA     0.0.0.0          1.1.1.1          0x80000003   484  0x20 0x8f98  36
NSSA    *0.0.0.0          1.1.1.2          0x80000003   470  0x20 0x899d  36
NSSA    *100.100.100.100  1.1.1.2          0x80000003   470  0x28 0x8333  36 <<<<<<<<<


Then, we check the database on VRF1. We should see the 100.100.100.100 route reaching

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   1.1.1.1          1.1.1.1          0x8000000b  1447  0x22 0xe92e  36
Router  *1.1.1.2          1.1.1.2          0x80000013   233  0x22 0xe029  36
Network *1.1.1.2          1.1.1.2          0x8000000d  2633  0x22 0x77a6  32
Summary *2.2.2.0          1.1.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  *1.1.1.2          1.1.1.2          0x80000006  2033  0x20 0x47cc  36
Router   2.2.2.2          2.2.2.2          0x80000006  2434  0x20 0x19f3  36
Network  2.2.2.2          2.2.2.2          0x80000004  1434  0x20 0x918d  32
Summary *1.1.1.0          1.1.1.2          0x80000005   833  0x20 0x4fe5  28
NSSA     100.100.100.100  2.2.2.2          0x80000005   434  0x28 0x8b23  36 <<<<< it is indeed being advertised by the peer as NSSA
Cause:
A VRF is mainly used for MPLS L3VPN deployments. We mostly use it to deploy OSPF between CE-PE. On this case, we are using the VRF to redistribute routes between tables. 

By default, OSPF acts as an ABR when configured in VRFs. As the routing-instance VRF1 detects VRF2 as an ABR and injecting the route into the area it doesn't redistribute the route 100.100.100.100 to area 0 to avoid a routing-loop. If we check the router 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 1.1.1.2 detail
 
    OSPF database, Area 0.0.0.31
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len
Router   1.1.1.2          1.1.1.2          0x80000004  1881  0x20 0x1dfd  36
  bits 0x3, link count 1
  id 1.1.1.2, data 1.1.1.2, Type Transit (2)
    Topology count: 0, Default metric: 1
  Topology default (ID 0)
    Type: Transit, Node ID: 1.1.1.2
      Metric: 1, Bidirectional
Network  1.1.1.2          1.1.1.2          0x80000002  2567  0x20 0xab7f  32
  mask 255.255.255.252
  attached router 1.1.1.2
  attached router 1.1.1.1
  Topology default (ID 0)
    Type: Transit, Node ID: 1.1.1.1
      Metric: 0, Bidirectional
    Type: Transit, Node ID: 1.1.1.2
      Metric: 0, Bidirectional
 
Bit 0x1 = ABR and bit 0x2 = ASBR, so bit 0x3 makes it an ASBR and ABR. ASBR as it is importing routes from another protocol (static) and ABR as as below explanation from Juniper Documents: 
 

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 1.1.1.2:10;
vrf-import VRF2-import;
vrf-export VRF2-export;
routing-options {
    static {
        route 100.100.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:

The solution to this problem is to configure the routing-instance as Virtual-router. The main difference between VRF and virtual router is that VRFs are used to work with MPLS capabilities while VRs 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 1.1.1.2 detail    
 
    OSPF database, Area 0.0.0.31
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Router   1.1.1.2          1.1.1.2          0x80000002     2  0x20 0xae78  36
  bits 0x2, link count 1
  id 1.1.1.0, data 255.255.255.252, Type Stub (3)
    Topology count: 0, Default metric: 1
 

With the routing-instances configured as virtual-routers the OSPF database shows the bits capabilities from routing-instance static as an ASBR. This will now install and flood the 100.100.100.100 IP 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  *1.1.1.1          1.1.1.1          0x80000015    15  0x22 0x3fc3  36
Router   1.1.1.6          1.1.1.6          0x80000014  1224  0x22 0xf506  36
Network  1.1.1.6          1.1.1.6          0x80000004  1224  0x22 0x71a9  32
Summary *1.1.1.0          1.1.1.1          0x80000011  1186  0x22 0x1f09  28
    OSPF AS SCOPE link state database
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern  *100.100.100.100   1.1.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   1.1.1.1          1.1.1.1          0x80000015    27  0x22 0x3fc3  36
Router  *1.1.1.6          1.1.1.6          0x80000014  1234  0x22 0xf506  36
Network *1.1.1.6          1.1.1.6          0x80000004  1234  0x22 0x71a9  32
Summary  1.1.1.0          1.1.1.1          0x80000011  1198  0x22 0x1f09  28
    OSPF AS SCOPE link state database
Type       ID               Adv Rtr           Seq      Age  Opt  Cksum  Len 
Extern   100.100.100.100   1.1.1.1          0x80000001  1193  0x22 0x4bd   36 <<<<<<< now received as type 5
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search