To understand this lab you need to grasp about the OSPF network types, DR/BDR requirements and if “neighbor” command should be used in each type. We summarized all of them into this table for your quick reference:
|Interface Types||Use DR/BDR?||Default Hello interval||Require “neighbor” command?|
Although we do believe the answer B “A neighbor statement needs to be configured in R1 and R3 pointing at each other” is better but in the exam you should choose answer C. Please read the explanation below.
Check the ports connecting between R1 and R3 via the “show running-config” command:
Or you can check these interfaces via the “show ip ospf interface S0/0” on R1 or “show ip ospf interface S1/1” on R3 you will see the Network types are “NON_BROADCAST” or “POINT_TO_MULTIPOINT”, respectively. For example:
Although the OSPF network types are mismatched but the Hello and Dead timers are still the same (30 seconds and 120 seconds, respectively) so an OSPF neighbor relationship can still be formed. But both interfaces are in “Non Broadcast” mode (no DR/BDR election) so they must have the “neighbor …” command under OSPF processes to form neighbor relationship.
We can check the OSPF neighborship on R3 first via the “show ip ospf neighbor” command:
We don’t see the OSPF neighborship between R3 and R4 (neighbor 220.127.116.11) so something was wrong with OSPF. So we continue checking with the “show running-config” command and pay attention to the OSPF config between R3 and R4.
We can realize the link between R3 and R4 is not running OSPF (missing the command “network 192.168.34.0 0.0.0.255 area 1”).
Check the configuration of R5 with the “show running-config” command:
Interface E0/0 of R5 is configured with OSPF authentication so we should check the configuration on interface E0/1 of R4:
There is no OSPF authentication under E0/1 of R4 so R4 cannot establish OSPF neighborship with R5.
Only the 18.104.22.168 subnets are not reachable from R4 so maybe something blocking it (OSPF neighborship is still formed between R4 and R6. You can verify with the “show ip ospf neighbor” command). Check the configuration of R6 with the “show running-config” command and pay attention to the OSPF part of R6:
From the output we learn that R6 is using distribute-lists to filter routes. Especially distribute-list 64 (note: 64 is the access-list number) is applied to:
+ Inbound direction on E0/1 (distribute-list 64 in Ethernet0/1): this distribute-list is no harm because it only prevents 22.214.171.124/8 prefix from learning back from E0/1. Notice that R6 can still advertise this prefix to the outside.
+ Outbound direction of all interfaces (distribute-list 64 out): this distribute-list is causing problem because it prevents 126.96.36.199/8 prefix from advertising to the outside ->R4 does not know how to reach 188.8.131.52 subnets. To fix this problem we should remove “distribute-list 64 out” on R6.
Note: Although the next line of this distribute-list allows prefix 184.108.40.206/16 but traffic for this prefix can never reach this line because the above line “access-list 64 deny 220.127.116.11 0.255.255.255” is always matched first and this prefix is dropped.