This section discusses the problems related to route installation. This means that OSPF routers have fully synchronized their databases with those of their neighbors but are not installing routes in the routing table.
After the route is in the database, there can be several reasons that the route is not installed in the database. This section discusses those reasons in detail and also tells how to solve these kinds of problems.
The most common reasons for OSPF failing to install routes in the routing table are as follows:
1. OSPF is not installing any routes in the routing table.
-
The network type is mismatched.
A mismatched network type produces a discrepancy in the database, and OSPF will not install those routes in the routing table. This situation is common in NBMA networks in which one side has a point-to-point network type and the other side has a broadcast network type. This problem also occurs if one side is defined as a point-to-multipoint network and the other side is left as nonbroadcast.
scenario: one side is defined as broadcast and the other side is defined as point-to-point. When an interface network type is defined as broadcast, OSPF considers that link to be a transit link and puts that link in its router LSA as a transit link.
show ip ospf interface
show ip ospf database router x.x.x.x
-output shows it is not reaching each other.
Solution: ensure both sides have the same network type. in this case make it both point to point.
Verification:
show ip route x.x.x.x
show ip ospf interface
-
IP addresses are flipped in dual serial-connected routers or a subnet/mask mismatch has occurred.
The IP addressing on dual serial interfaces can cause this problem. OSPF forms a FULL adjacency because the neighbor is still reachable, but this creates a discrepancy in the OSPF database.
This also can happen when the wrong IP subnet or mask is assigned on one side. This creates a discrepancy in the OSPF database.
show ip route ospf
-output shows no ospf route
show ip ospf neighbor
-output shows there is a ospf neighbor
Solution: assign the IP address on the correct corresponding interface.
Verification:
show ip route x.x.x.x
-
One side is a numbered and the other side is an unnumbered point-to-point link.
When OSPF creates a router LSA for point-to-point links, it adheres to the following rule to fill the Link ID and Link Data fields within the router LSA. Table shows that the Link Data field for unnumbered point-to-point links should have an MIB-II ifIndex value. Because the link data value of the numbered interface does not match that of the unnumbered interface, this creates the discrepancy in the OSPF database.
| 1 | Point-to-point Numbered | Neighbor's router ID | Interface IP address |
| 1 | Point-to-point Unnumbered | Neighbor's router ID | MIB-II ifIndex value |
show ip ospf database router
- output at both sides shows discrepancy in
"(Link Data) Router Interface address:"
Soloution:
make sure that both sides are either a numbered point-to-point link or
an unnumbered point-to-point link.
Verification:
show ip route x.x.x.x
-
A distribute list is blocking the routes' installation.
OSPF is a link-state protocol. When it forms an adjacency with any neighbor, it synchronizes its database with that neighbor. Because of its link-state nature, filtering in OSPF is not possible.
Configuring
distribute-list in prevents OSPF routes from being installed in the routing
table. This doesn't mean that the routes disappear from the OSPF database. It simply means that before OSPF installs the route into the routing table, it checks for the distribute list and installs only those networks that are permitted in the distribute list. However, it keeps the routes in the database.
show run | begin router ospf
- verify whether distribute-list in is configured.
show ip ospf database network
show ip route
Solution:
If a network is in the database but not in the routing table, make sure that the network is permitted in the distribute list.
Verification:
show ip route x.x.x.x
-
There is a broken PVC in a fully meshed Frame Relay network with the broadcast network type.
The OSPF network type broadcast should never be defined on a medium that is not fully meshed. Sometimes, the medium is fully meshed but the Layer 2 connectivity is not stable. In that case, when Layer 2 is broken, it creates an inconsistency and the medium becomes
non–fully meshed again.
show ip route ospf
- R1 is not installing any routes in the table.
Config shows all are broadcast type:
R1# ! interface Serial0.1 multipoint
ip address 131.108.0.1 255.255.255.0
ip ospf network broadcast _____________________________________________________________________________________ R2# ! interface Serial0.1 multipoint
ip address 131.108.0.2 255.255.255.0
ip ospf network broadcast _____________________________________________________________________________________ R3# ! interface Serial0.1 multipoint
ip address 131.108.0.3 255.255.255.0
ip ospf network broadcast
show ip ospf neighbor on all three routers. The output on R1 shows that it considers R2 to be the DR. However, the actual DR is R3, because it has the highest router ID. Because the link between R1 and R3 is broken, R1 declares R2 to be the DR.
show ip ospf database router
- output will show some discrepancies
Solution:
The solution in this case is to run a point-to-multipoint network type. With a point-to-multipoint network type, the flooding increases because no DR/BDR elected. If there is any
connectivity problem, however, it will not create any black holes.
So, a trade-off exists between reliability and increased flooding. Selecting a point-to-multipoint network type over unstable Frame Relay links provides reliability, while selecting a broadcast net-work type creates inconsistencies whenever any Layer 2 instability occurs.
Verification:
show ip route x.x.x.x
2. OSPF is not installing external routes in the routing table.
When OSPF redistributes any routes, whether connected, static, or from a different routing protocol, it generates a Type 5 LSA for those external routes. These Type 5 LSAs are
flooded into every OSPF router, with the exception of those in stub and NSSA areas. Sometimes, the problem is that the external routes are in the OSPF database but are not being installed in the routing table.
-
The forwarding address is not known through the intra-area or interarea route.
When OSPF learns an external LSA, it makes sure that the forwarding address is known through an OSPF intra-area or interarea route before it installs it into the routing table. If the forwarding address is not know through an intra-area or interarea route, OSPF will not install the route in the routing table. This is in accordance with the RFC 2328 standard.
show ip route 200.200.200.0
show ip ospf database external 200.200.200.0
- output shows the external route exists. with the forwarding address.
show ip route {forwarding address}
- forwarding routes is know via ospf external route. external type2
ABR is summarizing with an
area range command, so the more specific intra-area routes are summarized into one route.
R2#
router ospf 1
network 131.108.1.0 0.0.0.255 area 0
network 131.108.0.0 0.0.0.255 area 2
area 2 range 131.108.0.0 255.255.255.0
the ASBR is doing the redistribution from RIP into OSPF. It also shows that the connected networks in the range of 131.108.0.0/26 are being redistributed
into OSPF because RIP owns those connected routes. This configuration redistributes 131.108.0.4/26, which is a connected interface on R3.
R3#
router ospf 1
redistribute rip subnets
network 0.0.0.0 255.255.255.255 area 2
!
router rip
network 131.108.0.0
Solution:
R1 is seeing the forwarding address learned through OSPF external because R3 has redistribute connected under router ospf. This leaks a more specific route for the connected interfaces of R3. This also includes the forwarding address subnet, which is 131.108.0.4/26. Also, the intra-area route for this subnet is suppressed by R2 because R2 is summarizing 131.108.0.0/16. Because the more specific route always is preferred, R1 prefers the more specific external route of 131.108.0.4/26 over the less specific summarized route of 131.108.0.0/16.
This problem can be solved in two ways:
To implement the first solution, go to the ABR and remove the
area range command.
To implement the second solution, go to the ASBR and add a filter to control redistributed routes.
The filter actually prevents the route 131.108.0.0/26 from getting redistributed into OSPF as an external route because only 200.200.200.0 is permitted; all other routes are denied.
R3#
router ospf 1
redistribute rip subnets route-map no_connected
network 0.0.0.0 255.255.255.255 area 2
!
router rip
network 131.108.0.0
!
route-map no_connected permit 1
0 match ip address 1
!
access-list 1 permit 200.200.200.0 0.0.0.255
verification:
show ip route 200.200.200.0
show ip route 131.108.0.4 - forwarder address.
-
The ABR is not generating Type 4 summary LSAs.
One of the functions of a Type 4 summary LSA is to announce the reachability of an ASBR to the other areas. This Type 4 LSA is not required if the ASBR exists in the same area.
The ASBR doesn't generate the Type 4 summary LSA if it's not connected to area 0. To generate a summary LSA of Type 3 or Type 4, a router must have a connection into area 0. As a result, the external routes will not be installed in the network.
show ip route 200.200.200.0
- now route
show ip ospf database external 200.200.200.0
- confirming that the external route is in the database.
show ip ospf database asbr-summary 131.108.3.3
- no type 4 lsa for this route
The next logical step is to go on the ABR and see if it is indeed an ABR. If it does not consider itself an ABR, it will not generate any summary LSA of Type 3 or Type 4
If R2 were an ABR, the output would display "It's an area border router."
Solution:
In this example, R2 doesn't generate the Type 4 summary LSAs because it is not connected to area 0. To generate a summary LSA of Type 3 or Type 4, a router must have a connection into area 0.
To solve this problem, connect R2 to area 0 either physically or virtually by creating a virtual link, as
By configuring a virtual link on R2, the router is now virtually connected to area 0; therefore, it now considers itself an ABR
show ip ospf
Now, get on R1 again and see if the Type 4 LSA is being received.
show ip ospf database asbr-summary
Because the Type 4 LSA now is being generated, R1 installs the external routes in its routing table
show ip route 200.200.200.0
thqqqqqqqqqqqqqqqqqqq so much ,
ReplyDeletevery excellent topic