Lab 26: Securing OSPF with MD5 Authentication
Unauthenticated OSPF trusts any router that speaks it — a rogue device can inject routes and redirect traffic. Add MD5 authentication so only routers knowing the key can form adjacencies. Difficulty: Intermediate+ · Time: ~25 min.
Lab objectives
- Start with working (unauthenticated) OSPF between two routers
- Enable MD5 authentication on the link
- Watch the adjacency drop when keys mismatch
- Restore matching keys and verify FULL again
Topology & addressing
R1—R2 on 10.0.12.0/30, each with a LAN, OSPF area 0 already running (as in Lab 6).
Step-by-step configuration
Both routers, on the link interface:ip ospf message-digest-key 1 md5 SecretKey1ip ospf authentication message-digest | Key number AND key string must match both ends |
Test the failure: change R2's key to WrongKey | Adjacency drops within dead-timer — watch the neighbor table empty |
| Restore matching keys | Adjacency re-forms to FULL |
Verification
show ip ospf neighbor — FULL with matching keys, empty with mismatched ones. show ip ospf interface confirms "Message digest authentication enabled". The lesson sticks in the failure: mismatch = silent adjacency death, so key management discipline matters.
Next lab: labs hub · test yourself: CCNA practice test.
Frequently asked questions
Why authenticate OSPF at all?
Without it, any device speaking OSPF can join the domain and inject or manipulate routes — authentication ensures only trusted routers participate.
What happens when authentication keys mismatch?
The routers reject each other's hellos, the adjacency drops after the dead timer, and routes learned via that neighbor disappear.
Do all routers in an area need the same key?
Keys are configured per-link — both ends of each link must match, but different links can use different keys.
Related articles
Want hands-on training?
Learn this on real Cisco lab devices with placement support at Attila Technologies, Ahmedabad.