Lab Objective
Diagnose and resolve three independently introduced faults — an EIGRP stub router incorrectly advertising a summary route it should not, an OSPF Type 3 filter blocking more routes than intended, and an NTP authentication mismatch preventing time synchronization — using the same systematic, evidence-based troubleshooting approach established throughout this series.
Lab Purpose
This lab combines faults across the EIGRP stub, OSPF filtering, and NTP authentication technologies covered in the three most recent labs, reinforcing that recently learned advanced features are just as susceptible to configuration mistakes as fundamental technologies, and that the same verification-first troubleshooting discipline applies regardless of a technology's complexity or novelty.
Lab Topology
Branch (EIGRP stub, should advertise ONLY
connected routes)
Hub (ABR between OSPF areas, filtering
specific Type 3 LSAs)
NTP-Client (should sync with authenticated
NTP-Server)
Three faults have been deliberately
introduced across these three systemsTask 1: Confirm the Reported Symptoms
A hub router unexpectedly sees a route it should not from the stub branch, an OSPF area is missing a route that should legitimately propagate, and a client's clock has drifted noticeably from the server. Confirm all three symptoms.
Task 2: Diagnose and Resolve the EIGRP Stub Fault
Examine the stub router's configuration and the hub's neighbor table to identify why an unexpected route is being advertised.
Task 3: Diagnose and Resolve the OSPF Filter Fault
Examine the ABR's filter-list and prefix-list configuration to identify why a legitimate route is being blocked.
Task 4: Diagnose and Resolve the NTP Authentication Fault
Examine both the server's and client's NTP authentication configuration to identify the source of the mismatch.
Task 5: Verify All Symptoms Are Resolved
Confirm the stub advertises correctly, the intended OSPF route propagates, and NTP synchronization succeeds.
Solution and Verification
-- Fault 1: EIGRP stub misconfiguration
Hub# show ip eigrp neighbors detail
Stub Peer Advertising ( CONNECTED SUMMARY )Routes
-- The stub is advertising BOTH connected
-- and summary routes, but the design
-- intent was connected-only -- FAULT 1
-- IDENTIFIED: an unintended "summary"
-- keyword was added to the stub
-- configuration
Branch(config)# router eigrp 100
Branch(config-router)# no eigrp stub connected summary
Branch(config-router)# eigrp stub connected
-- Corrected: stub now restricted to
-- connected routes only, matching the
-- original design intent-- Fault 2: OSPF filter overreach
Hub# show ip prefix-list BLOCK-71
ip prefix-list BLOCK-71: 2 entries
seq 5 permit 192.168.70.0/24
seq 10 deny 0.0.0.0/0 le 32
-- The prefix list is matching
-- 192.168.70.0/24 (the route that SHOULD
-- propagate) instead of 192.168.71.0/24
-- (the one that should be blocked) --
-- FAULT 2 IDENTIFIED: wrong prefix
-- specified in the filtering list
Hub(config)# ip prefix-list BLOCK-71 seq 5 permit 192.168.71.0/24
-- (Note: sequence numbers cannot be
-- directly overwritten with different
-- match criteria in some IOS versions;
-- remove and re-add if necessary)
Hub(config)# no ip prefix-list BLOCK-71 seq 5
Hub(config)# ip prefix-list BLOCK-71 seq 5 permit 192.168.71.0/24
-- Corrected: filter now matches the
-- intended route-- Fault 3: NTP authentication mismatch
NTP-Client# show running-config | include ntp
ntp authentication-key 1 md5 NtpSecure2026
ntp trusted-key 1
ntp authenticate
ntp server 10.15.15.1
-- The server statement is missing the
-- "key 1" clause entirely -- FAULT 3
-- IDENTIFIED: client is attempting
-- unauthenticated NTP against a server
-- that requires authentication
NTP-Client(config)# no ntp server 10.15.15.1
NTP-Client(config)# ntp server 10.15.15.1 key 1
-- Corrected: server reference now
-- includes the required key clauseHub# show ip eigrp neighbors detail
Stub Peer Advertising ( CONNECTED )Routes
-- Stub now correctly restricted
Area0-Router# show ip route ospf | include 192.168.71
O IA 192.168.71.0/24 [110/65] via 10.2.2.1
-- Intended route now propagating correctly
NTP-Client# show ntp associations
*~10.15.15.1 127.127.1.1 3 8 64 17 4.1 0.234
-- Authenticated synchronization restoredKey Takeaway
Even advanced, recently introduced technologies produce the same kind of specific, verifiable signature every fault throughout this series has shown — an unexpected keyword in a stub declaration, a mismatched prefix in a filter list, a missing clause in a server reference — reinforcing that the systematic approach of checking the exact configuration state relevant to each symptom, rather than assuming familiarity with a technology means skipping careful verification, remains the correct troubleshooting discipline regardless of how sophisticated the feature involved happens to be.