120 Labs for Cisco CCNA 200-125 and CCENT Exams

Lab 81: Debugging OSPF Adjacencies

Lab Objective:

The objective of this lab exercise is for you to learn and understand how to debug OSPF adjacencies.

Lab Purpose:

Debugging OSPF adjacencies is a fundamental troubleshooting skill. Using debugging, you can identify issues that may be causing OSPF to stop operating. As a Cisco engineer, as well as in the Cisco CCNA exam, you will be expected to know how to decipher OSPF adjacency debugging messages.

Certification Level:

This lab is suitable for ICND2 and CCNA certification exam preparation.

Lab Difficulty:

This lab has a difficulty rating of 7/10.

Readiness Assessment:

When you are ready for your certification exam, you should complete this lab in no more than 10 minutes.

Lab Topology:

Please use the following topology to complete this lab exercise:

Task 1:

Configure hostnames on R1, R2, and Sw1 as illustrated in the topology.

Task 2:

Configure VLAN4010 on Sw1 and name it OSPF_VLAN. Assign ports FastEthernet0/2 and FastEthernet0/3 to this VLAN as access ports. Configure IP addressing on R1 and R2 FastEthernet0/0 interfaces.

Task 3:

Enable OSPF in area 0 between R1 and R2. For R1, use OSPF process ID 1, and for R2, use OSPF process ID 2. Verify that your OSPF adjacency has formed between R1 and R2. Also verify that the default network type for the Ethernet link between R1 and R2 is broadcast.

Task 4:

Enable OSPF adjacency debugging on R1 using the debug ip ospf adj command. Reset the OSPF process on R2. As the OSPF adjacency re-establishes, verify that you can see the different states that OSPF transitions through as it moves to the FULL state.

Configuration and Verification

Task 1:

For reference information on configuring hostnames, please refer to earlier labs.

Task 2:

For reference information on configuring VLANs and IP addressing, please refer to earlier labs.

Task 3:

For reference information on configuring OSPF, please refer to earlier labs.

Task 4:

R2#debug ip ospf adj 
OSPF adjacency events debugging is on 
R2#clear ip ospf process 
Reset ALL OSPF processes? [no]: yes 
*Mar  1 02:13:21.660: OSPF: Elect BDR 0.0.0.0 
*Mar  1 02:13:21.660: OSPF: Elect DR 0.0.0.0 
*Mar  1 02:13:21.660:        DR: none    BDR: none 
*Mar  1 02:13:21.660: OSPF: Remember old DR 192.168.20.1 (id) 
*Mar  1 02:13:21.721: OSPF: Interface FastEthernet0/0 going Up 
*Mar  1 02:13:21.721: OSPF: i_up : interface is down 
*Mar  1 02:13:21.725: OSPF: 2 Way Communication to 192.168.20.1 on FastEthernet0/0, state 2WAY 
*Mar  1 02:13:21.725: OSPF: Backup seen Event before WAIT timer on FastEthernet0/0 
*Mar  1 02:13:21.725: OSPF: DR/BDR election on FastEthernet0/0 
*Mar  1 02:13:21.725: OSPF: Elect BDR 10.1.1.2 
*Mar  1 02:13:21.729: OSPF: Elect DR 192.168.20.1 
*Mar  1 02:13:21.729: OSPF: Elect BDR 10.1.1.2 
*Mar  1 02:13:21.729: OSPF: Elect DR 192.168.20.1
*Mar  1 02:13:21.729:        DR: 192.168.20.1 (Id)   BDR: 10.1.1.2 (Id) 
*Mar  1 02:13:21.729: OSPF: Send DBD to 192.168.20.1 on FastEthernet0/0 seq 0x1614 opt 0x52 flag 0x7 len 32
*Mar  1 02:13:21.733: OSPF: Rcv DBD from 192.168.20.1 on Ethernet0/0 seq 0xEB3 opt 0x52 flag 0x7 len 32  mtu 1500 state EXSTART 
*Mar  1 02:13:21.737: OSPF: NBR Negotiation Done. We are the SLAVE 
*Mar  1 02:13:21.737: OSPF: Send DBD to 192.168.20.1 on FastEthernet0/0 seq 0xEB3 opt 0x52 flag 0x0 len 32 
*Mar  1 02:13:21.741: OSPF: Rcv DBD from 192.168.20.1 on FastEthernet0/0 seq 0xEB4 opt 0x52 flag 0x3 len 172  mtu 1500 state EXCHANGE 
*Mar  1 02:13:21.741: OSPF: Send DBD to 192.168.20.1 on FastEthernet0/0 seq 0xEB4 opt 0x52 flag 0x0 len 32 
*Mar  1 02:13:21.749: OSPF: Rcv DBD from 192.168.20.1 on FastEthernet0/0 seq 0xEB5 opt 0x52 flag 0x1 len 32  mtu 1500 state EXCHANGE 
*Mar  1 02:13:21.749: OSPF: Exchange Done with 192.168.20.1 on FastEthernet0/0 
*Mar  1 02:13:21.749: OSPF: Send LS REQ to 192.168.20.1 length 84 LSA count 7 
*Mar  1 02:13:21.749: OSPF: Send DBD to 192.168.20.1 on FastEthernet0/0 seq 0xEB5 opt 0x52 flag 0x0 len 32 
*Mar  1 02:13:21.753: OSPF: Rcv LS UPD from 192.168.20.1 on FastEthernet0/0 length 332 LSA count 7 
*Mar  1 02:13:21.757: OSPF: Synchronized with 192.168.20.1 on FastEthernet0/0, state FULL 
*Mar  1 02:13:21.757: %OSPF-5-ADJCHG: Process 2, Nbr 192.168.20.1 on FastEthernet0/0 from LOADING to FULL, Loading Done 
*Mar  1 02:13:26.544: OSPF: Rcv LS UPD from 192.168.20.1 on FastEthernet0/0 length 64 LSA count 1 
*Mar  1 02:13:27.001: OSPF: Rcv LS UPD from 192.168.20.1 on FastEthernet0/0 length 64 LSA count 1R2#undebug all 
All possible debugging has been turned off 
R2#

NOTE: From the output above, you can clearly see OSPF transition from the 2WAY state to the EXSTART state to the EXCHANGE state and, finally, to the FULL state. Because this is a broadcast network type, a DR and BDR router are also elected. If this were a point-to-point or point-to-multipoint network type, you would not see the DR and BDR election taking place.

Related Articles

Subscribe
Notify of
guest

This site uses Akismet to reduce spam. Learn how your comment data is processed.

0 Comments
Inline Feedbacks
View all comments
Back to top button