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

[ScreenOS] What could be the reason for LSA present in the OSPF database, but not populated in the routing table?

0

0

Article ID: KB13547 KB Last Updated: 28 Mar 2020Version: 2.0
Summary:

This article explains one the most common reasons a specific LSA is present in the OSPF database, but the network is not populated in the routing table.

 

Symptoms:

In the example taken below, It is noticed that a network (10.129.0.0/19) is missing from the routing table. The router is running OSPF and the OSPF database investigation is showing that the LSA for the missing network can be found in the database:

AS External LSA(s)  

Link-State-Id   Adv-Router-Id     Age   Sequence#   CheckSum 
--------------------------------------------------------------------------------
   10.129.0.0      10.190.0.2    1572  0x800000df     0x8920 

Since this LSA is Type-5 (External), it is checked that the corresponding Type-4 (ASBR summary) LSA can be found in the database. This is also true:
ASBR LSA(s) for area 0.0.0.100

Link-State-Id   Adv-Router-Id     Age   Sequence#   CheckSum
--------------------------------------------------------------------------------
   10.190.0.2      10.224.0.1    1292  0x800000df     0x4c3a

The Adv-Router-Id can be further found in the routing table:
          ID          IP-Prefix      Interface         Gateway  P Pref    Mtr     Vsys
--------------------------------------------------------------------------------------
*      34457      10.224.0.1/32         eth3/2      10.231.3.1  O   60      2     Root

At this point, even setting a static route for the ASBR (10.190.0.2) was tried, but this does not help. Why?

The answer can be found if you investigate the missing network LSA:
get vr trust-vr protocol ospf database det ext    

----------------------------------  
AS External LSA(s)  
--------------------------------  
Age: 365  
Seq Number: 0x8000013a  
Checksum: 0xd17c  
Advertising Router: 10.190.0.2  
Link State ID: 10.129.0.0  
Length: 36  
Options: DC  
Network Mask: 255.255.224.0  
Metric Type: 2  
TOS: 0  
Metric: 20  
Forward Address: 10.191.2.4  
External Route Tag: 1292 

This LSA has set a Forward Address to a value different than 0.0.0.0.

According to RFC 2328, Section 16.4. (Calculating AS external routes):

"If the forwarding address is non-zero, look up the forwarding address in the routing table. The matching routing table entry must specify an intra-area or inter-area path; if no such path exists, do nothing with the LSA and consider the next in the list."

The routing table was missing an intra- or inter-area route for the Forward Address and that is the root cause for the issue.

 

Solution:

The next troubleshooting step is to find why we are missing the LSA for the Forward-Address.

One of the main reasons this happens is that there could be LSA filtering set on the neighbor router for the forward address LSA. When this filtering is corrected, the network is populated in the routing table as expected.

 

Modification History:

2020-03-28: Article checked for accuracy and validity; minor changes made

 

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