Refer to the exhibit. You are the network administrator responsible for the NProuter, the 10.1.1.1 router, and the 10.1.1.2 router. What can you determine about the OSPF operations from the debug output?
NProuter#debug ip ospf events
OSPF events debugging is on
A. The NProuter has two OSPF neighbors in the “Full” adjacency state.
B. The NProuter serial0/0 interface has the OSPF dead timer set to 10 seconds.
C. The NProuter serial0/0 interface has been configured with an OSPF network type of “point-to-point”.
D. The 10.1.1.1 and 10.1.1.2 routers are not using the default OSPF dead and hello timers setting.
E. The “Mismatched” error is caused by the expiration of the OSPF timers.
First we should understand clearly about the line
Dead R 120 C 10, Hello R 30 C 30
The “R” here means “Received” and “C” means “Configured”. In other words, “Dead R” is the Dead Timer Received from the neighbor and the “Dead C” is the Dead Timer of the local router.
Therefore in this case “Dead R 120 C 10″ means the Death Timer of the neighbor is 120 seconds while the local Dead Timer is 10 seconds, which causes a mismatch. Also we can learn that the local OSPF dead timer is set to 10 seconds -> B is correct.
For your information, by default, OSPF uses a 10-second hello timer and 40-second hold timer on broadcast and point-to-point links, and a 30-second hello timer and 120-second hold timer for all other network types. So we can’t confirm answer D is correct or not.
You have just completed an OSPF implementation. While executing your verification plan, you determine that R1 is not able to establish full OSPF adjacency with R2. The show ip ospf neighbor command output on R1 shows that R2 is stuck in the INIT state.
What could be the cause of this problem?
A. DR and BDR election errors between R1 and R2.
B. The R2 router has not received the OSPF hello packets from the R1 router.
C. Mismatched interface maximum transmission unit (MTU) configuration between the R1 and R2.
D. Mismatched OSPF hello interval configuration between the R1 and R2.
E. Corrupted LSAs exchanges between the R1 and R2.
When a router receives an OSPF Hello from a neighbor, it sends the Hello packet by including that neighbor’s router ID in the Hello packet. If the neighbor does not receive this packet (means that it doesn’t see itself in this packet), it will be stuck in INIT state. INIT state can be understood as a one-way Hello. An example of a router stuck in INIT state is shown below:
Refer to the exhibit. You have completed an OSPF implementation, and you are verifying OSPF operation. You notice that router A and router B are stuck in the two-way state. From the show ip ospf interface command output, what is the cause of this issue?
A. All OSPF implementations must have at least one interface in area 0.
B. You are attempting to run in the broadcast mode over an NBMA interface.
C. Both routers are configured to function as a BDR; therefore, there is no DR router.
D. Someone has changed the OSPF router ID; therefore you must clear the OSPF process.
E. The OSPF priority is set to 0 on both routers; therefore neither can become the DR.
When OSPF adjacency is formed, a router goes through several state changes before it becomes fully adjacent with its neighbor. The states are Down, Attempt, Init, 2-Way, Exstart, Exchange, Loading, and Full.
An OSPF neighbor reaches the 2-way state when bidirectional communication is established (each router has seen the other’s hello packet). This is the beginning of an OSPF adjacency. On broadcast media and non-broadcast multiaccess networks, the DR and BDR are elected in this state. But the priority on both routers are 0 so no DR and BDR are elected -> These routers stay in the 2-way state.
(Reference and a good resource of OSPF Neighbor states: http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a0080093f0e.shtml)
You have completed an OSPF implementation, and you are verifying OSPF operation. During this verification, you notice that the OSPF route of 172.16.10.0 is repeatedly appearing and disappearing from the routing table. Further investigation finds that the OSPF CPU utilization is very high and the routers are constantly performing SPF calculations. You determine that 172.16.20.2 is the source of the 172.16.10.0 route. Using the show ip ospf database router 172.16.20.1 command, you notice that when this show command is performed repeatedly, the contents of the LSA change every few seconds.
What could be the cause of this problem?
A. OSPF authentication errors between some of the routers.
B. Two routers have the same OSPF router ID.
C. Issues with mistuned OSPF timers.
D. OSPF LSA pacing issues between some of the routers.
E. OSPF neighbor adjacency problems between some of the routers.
The maximum number of routers per OSPF area typically depends on which three factors? (Choose three)
A. the kind of OSPF areas being implemented
B. the number of external LSAs in the network
C. the number of DRs and BDRs in the areas
D. the number of virtual links in the areas
E. how well the areas can be summarized
F. the use of LSA filters
Answer: A B E