Why cannot an OSPF route that exists in the LSDB be found in the routing table

15

Perform the following steps to solve this problem:

Check whether the IP address is valid.
Check whether the forwarding address is known and reachable.
Check whether the routes are summarized or redistributed correctly.
Check whether different masks or IP addresses are used in the Peer-to-peer (P2P) connection.
Check whether route lists are advertised.
Check whether the backbone area is disconnected.
Check whether OSPF is enabled on the secondary address but not on the primary address.
Parent topic: IP Routing

Other related questions:
Why cannot an OSPF route contained in the LSDB/LSA be queried in the routing table on an S series switch
Question: Why cannot an OSPF route contained in the LSDB/LSA be queried in the routing table? Answer: Perform the following operations on the S series switch to solve the problem. Check whether the IP address is valid. Check whether the forwarding address is known and reachable. Check whether the route aggregation or route import is correct. Check whether a different mask or IP address is used in P2P connection. Check whether the advertise route list is configured. Check whether the connection with the backbone area is proper. Check whether OSPF is enabled on the secondary IP address instead of the primary IP address.

Why are routes in the OSPF routing table on an S series switch in the inactive state
A policy that filters all OSPF routes may be configured in an OSPF process. As a result, all routes in the OSPF routing table are in the inactive state.

Why cannot OSPF import BGP routes
As defined in RFC 1364, OSPF cannot import IBGP routes. Routes learned via IBGP must not be imported into OSPF OSPF, however, can import IBGP routes on a PE. BGP routes exist in a VPNv4 routing table on a device functioning as a PE but cannot be imported to OSPF. This is because the role of the device changes from a PE to an MCE after the vpn-instance-capability simple command in run in the OSPF process. Solution: If the device needs to function as a PE, you need to run the undo vpn-instance-capability command on the device.

Why the number of routes in the OSPF routing table of the OSPF VPN multi-instance is less than the predicted number
In the OSPF VPN multi-instance, loops may occur if PEs and CEs learn BGP and OSPF routes from each other. You can set the DN in Type3, Type5, or Type7 LSAs advertised by PEs to 1 so that CEs ignore the LSAs with the DN value of 1. These LSAs are not used in route calculation, which prevents loops. If the preceding method is used to prevent loops, the number of routes in the OSPF routing table is less than the predicted number. To use the LSAs with DN 1 in route calculation, run the vpn-instance-capability simple command on CEs to disable routing loop detection.

External routes imported using OSPF on a CE series switch cannot be viewed in the routing table
This problem is caused by routing loop detection. By default, routing loop detection is enabled on a CE series switch. When OSPF VPN multi-instance is deployed on a Multi-VPN-Instance CE (MCE) device, and DN Bit is set in Type 3, Type 5, or Type 7 LSAs, corresponding routes cannot be calculated and viewed in the routing table because routing loop detection is performed during OSPF route calculation. To address this problem, run the vpn-instance-capability simple command on the MCE device to disable routing loop detection of the OSPF instance.

If you have more questions, you can seek help from following ways:
To iKnow To Live Chat
Scroll to top