<div><img src="https://skillset.s3.amazonaws.com/img/question/42493/54d0033c-2e28-4c75-b04a-4fb30a0009b0" /></div> Refer to the exhibit. OSPF has been correctly configured on R1 and R2. The command default-information originate is also applied on R2. Remote LANs are able to communicate with each other. However, a ping sourced from R1s interface Fa0/0 to a Google public DNS address is unsuccessful. What can be concluded about the output of the show command on each router that affects the connectivity to the Internet?

Refer to the exhibit. OSPF has been correctly configured on R1 and R2. The command default-information originate is also applied on R2. Remote LANs are able to communicate with each other. However, a ping sourced from R1s interface Fa0/0 to a Google public DNS address is unsuccessful. What can be concluded about the output of the show command on each router that affects the connectivity to the Internet?

Any packet destined to 8.8.8.8 sourced from R1s Fa0/0 interface address will fail because of a routing loop

Because the route for IP address 8.8.8.8 is not known to R2s routing table, it will not be forwarded to any of R2s directly connected interfaces

The IP address of the Loopback interface is invalid

Any packet destined to 8.8.8.8 will be dropped immediately because the IP destination address is invalid

Explanation

The question states that the OSPF is configured correctly and the default-information originate command is also applied so this is not an OSPF configuration problem. The "show" commands however, shows that the default route 0.0.0.0/0 (as connoted by S*) is pointed at R1s serial 2/1 interface (10.1.1.1 as shown on the output of show ip interface brief command) instead of using R2s serial s2/0 interface as outbound interface or next-hop ip address to the Internet side. So, any packet destined to a network that is not referenced to R1s routing table will be forwarded to R2 (note that the "default-information originate" command is enabled on this router), R2 will then send back the packet to the next-hop address of 10.1.1.1 (which is R1s serial s2/1 interface) which creates a routing loop. To test this, you can issue the command traceroute 8.8.8.8 source 172.16.0.1 command on R1 and you will notice that the packet will be hopping back and forth to R1 and R2 then finally drops it after the TTL reaches its limit. (http://www.cisco.com/c/en/us/support/docs/ip/open-shortest-path-first-ospf/47868-ospfdb9.html), (http://www.cisco.com/c/en/us/td/docs/security/asa/asa82/configuration/guide/config/route_static.html#wp1121567)