Look at the following exhibit carefully; there is no route to 10.1.4.0/24 in the local routing table.
According to the output of R1 in the exhibit, can you tell me why 10.1.4.0/24 is not in R1’s routing
table?

A.
The forwarding address, 10.1.3.2, is also redistributed into OSPF, and an OSPF external route
cannot use another OSPF external as its next hop

B.
R3 is not redistributing 10.1.4.0/24 properly.

C.
R2 is not properly configured as an Area Border Router

D.
Area 1 is a stub area, and external routes cannot be originated in a stub area.

Explanation:
Network Missing from the Routing Table
R2515 has a RIP (R) derived route for network 200.1.1.0/24. R2515 is the ASBR and redistributes

the RIP protocol into OSPF. R2504 learns about network 200.1.1.0/24 from R2515 and installs it in
its routing table as an OSPF external type 2 (E2) route. The problem is that R2507 does not have
network 200.1.1.0/24 in its routing table.
R2507 has external routes for networks 3.3.4.0/24, 3.22.88.0/24 and 3.44.66.0/24, even though all
of these networks should be included in the summary of 3.0.0.0/8.
The reason these external routes show up is that the ASBR, which redistributes RIP into OSPF,
has RIP running on these three subnets. It therefore redistributes the subnets as external routes
into OSPF. Since these subnets are external routes, they are not summarized by the ABR
(R2504). External OSPF routes can only be summarized by the ASBR. In this case, R2515. The
ABR summarizes only internal OSPF routes from area 1 into area 0.
Note: With the fix of Cisco bug ID CSCdp72526 (registered customers only) , OSPF does not
generate a type-5 link-state advertisement (LSA) of an overlapped external network. R2507 only
has a summary inter-area route of 3.0.0.0/8. Then, R2507 installs 200.1.1.0/24 as the forwarding
address and it is reachable via interarea route 3.0.0.0/8. This is in compliance with RFC 2328.
This output shows the external LSA for network 200.1.1.0/24 in the OSPF database of R2507:
R2507# show ip ospf data external 200.1.1.0
OSPF Router with ID (7.7.7.1) (Process ID 1)
Type- 5 AS External Link States
LS age: 72
Options: (No TOS- capability, DC)
LS Type: AS External Link
Link State ID: 200.1.1.0 (External Network Number )
Advertising Router: 3.44.66.3
LS Seq Number: 80000001
Checksum: 0xF161
Length: 36
Network Mask: /24
Metric Type: 2 (Larger than any link state path)
TOS: 0
Metric: 20
Forward Address: 3.3.4.4
External Route Tag: 0
OSPF allows the ASBR to specify another router as the forwarding address to external routes. In
this case, the
ASBR (R2515) has specified 3.3.4.4 as the forwarding address for the external network 200.1.1.0.
RFC 2328 , section 16.4 (Calculating AS external routes), states:
“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.”

In this example, the route to the forwarding address 3.3.4.4 is shown here:
R2507#
show ip route 3.3.4.4
Routing entry for 3.3.4.0/ 24
Known via “ospf 1”, distance 110, metric 20, type extern 2, forward
metric 70
Redistributing via ospf 1
Last update from 1.1.1.2 on Serial0, 00: 00: 40 ago
Routing Descriptor Blocks:
* 1.1.1.2, from 3.44.66.3, 00: 00: 40 ago, via Serial0
Route metric is 20, traffic share count is 1
The forwarding address of 3.3.4.4 is matched by the external route 3.3.4.0/24 instead of the interarea summary route 3.0.0.0/8 due to the longest match rule. Because the router does not have an
internal OSPF route to the forwarding address, it does not install the external route 200.1.1.0/24 in
the routing table. The use of an external route to reach another external route may lead to loops.
Therefore OSPF does not permit it.

http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405a.shtml