A customer network engineer has edited their OSPF network configuration and now your customer is experiencing network issues. They have contacted you to resolve the issues and return the network to full functionality.
Question 1
The OSPF neighbor relationship has been lost between R1 and R3. What is causing this problem?
A. The serial interface in R1 should be taken out of the shutdown state.
B. A neighbor statement needs to be configured in R1 and R3 pointing at each other.
C. The R1 network type should be changed to point-to-multipoint non-broadcast.
D. The hello, dead and wait timers on R1 need to be reconfigured to match the values on R3.
B. A neighbor statement needs to be configured in R1 and R3 pointing at each other.
C. The R1 network type should be changed to point-to-multipoint non-broadcast.
D. The hello, dead and wait timers on R1 need to be reconfigured to match the values on R3.
Answer: C
Explanation
Check the ports connecting between R1 and R3 via the “show running-config” command:
R1#show running-config
<
<
R3#show running-config
<
<
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:
Question 2
Connectivity from R3 to R4, R5 and R6 has been lost. How should connectivity be reestablished?
A. Configure R4 with a virtual link to 192.168.13.2
B. Change the R3 and R4 hello-interval and retransmit-interface timers to zero so the link won’t go down.
C. Add an OSPF network statement for 4.4.4.4 0.0.0.0 area 1 in R3
D. Add an OSPF network statement for 192.168.34.3 0.0.0.255 area 2 in R3
E. Add an OSPF network statement for 192.168.34.0 0.0.0.255 area 1 in R3
B. Change the R3 and R4 hello-interval and retransmit-interface timers to zero so the link won’t go down.
C. Add an OSPF network statement for 4.4.4.4 0.0.0.0 area 1 in R3
D. Add an OSPF network statement for 192.168.34.3 0.0.0.255 area 2 in R3
E. Add an OSPF network statement for 192.168.34.0 0.0.0.255 area 1 in R3
Answer: E
Explanation
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 4.4.4.4) 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″).
Question 3
After resolving the issues between R3 and R4, Area 2 is still experiencing routing issues. Based on the current router configurations, what needs to be resolved for routes to the networks behind R5 to be seen in the company intranet?
A. Configure R4 and R5 to use MD5 authentication on the Ethernet interfaces that connect to the common subnet.
B. Configure Area 1 in both R4 and R5 to use MD5 authentication.
C. Add “ip ospf authentication-key 7 BEST” to the R4 Ethernet interface that connects to R5 and “ip ospf authentication-key 7 BEST” to R5 Ethernet interface that connects to R4.
D. Add “ip ospf authentication-key CISCO” to R4 Ethernet 0/1 and add “area 2 authentication” to the R4 OSPF routing process.
B. Configure Area 1 in both R4 and R5 to use MD5 authentication.
C. Add “ip ospf authentication-key 7 BEST” to the R4 Ethernet interface that connects to R5 and “ip ospf authentication-key 7 BEST” to R5 Ethernet interface that connects to R4.
D. Add “ip ospf authentication-key CISCO” to R4 Ethernet 0/1 and add “area 2 authentication” to the R4 OSPF routing process.
Answer: D
Explanation
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/0 of R4:
There is no OSPF authentication under E0/1 of R4 so R4 cannot establish OSPF neighborship with R5.
Question 4
The 6.6.0.0 subnets are not reachable from R4. how should the problem be resolved?
A. Edit access-list 46 in R6 to permit all the 6.6.0.0 subnets.
B. Apply access-list 46 in R6 to a different interface.
C. Apply access-list 1 as a distribute-list out under router ospf 100 in R4.
D. Remove distribute-list 64 out on R6.
E. Remove distribute-list 1 in ethernet 0/1 in R4.
F. Remove distribute-list 1 in ethernet 0/0 in R4.
B. Apply access-list 46 in R6 to a different interface.
C. Apply access-list 1 as a distribute-list out under router ospf 100 in R4.
D. Remove distribute-list 64 out on R6.
E. Remove distribute-list 1 in ethernet 0/1 in R4.
F. Remove distribute-list 1 in ethernet 0/0 in R4.
Answer: D
Explanation
Only the 6.6.0.0 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 6.0.0.0/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 6.0.0.0/8 prefix from advertising to the outside ->R4 does not know how to reach 6.6.0.0 subnets. To fix this problem we should remove “distribute-list 64 out” on R6.
+ Inbound direction on E0/1 (distribute-list 64 in Ethernet0/1): this distribute-list is no harm because it only prevents 6.0.0.0/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 6.0.0.0/8 prefix from advertising to the outside ->R4 does not know how to reach 6.6.0.0 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 6.6.0.0/16 but traffic for this prefix can never reach this line because the above line “access-list 64 deny 6.0.0.0 0.255.255.255″ is always matched first and this prefix is dropped.
No comments:
Post a Comment