1. show ip protocols
2. show ip ospf
3. show ip ospf interface
4. show ip ospf neighbor
5. show ip ospf database
6. debug ip ospf packet
7. debug ip ospf hello
8. debug ip ospf adj
Using show ip protocols command to verify and troubleshoot OSPF
As with other routing protocols, show ip protocols helps verify the global configuration of OSPF. The output of this protocol from RouterA in our network is shown below:
RouterA#sh ip protocols
Routing Protocol is “ospf 1”
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Router ID 192.168.2.1
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
0.0.0.0 255.255.255.255 area 1
Reference bandwidth unit is 100 mbps
Routing Information Sources:
Gateway Distance Last Update
192.168.3.2 110 08:25:40
Distance: (default is 110)
The first thing to notice in the above output is the router ID and the areas configured on this router. It also shows the networks that are added to the process. The final thing to notice is that the adjacent router is shown as the Routing Information Source. As you can see, the output from this command can be used to quickly verify the basic configuration and it is easy to catch any configuration mistake in this small output.
Using show ip ospf command to verify and troubleshoot OSPF
The show ip ospf command is also useful to verify configuration. While most of the output is out of scope of CCNA, a few things such as Router ID, Area related information, and SPF related information is useful. The output from RouterA is shown below:
RouterA#show ip ospf
Routing Process “ospf 1” with ID 192.168.2.1
Start time: 00:00:07.616, Time elapsed: 08:36:11.732
Supports only single TOS(TOS0) routes
Supports opaque LSA
Supports Link-local Signaling (LLS)
Supports area transit capability
Router is not originating router-LSAs with maximum metric
Initial SPF schedule delay 5000 msecs
Minimum hold time between two consecutive SPFs 10000 msecs
Maximum wait time between two consecutive SPFs 10000 msecs
Incremental-SPF disabled
Minimum LSA interval 5 secs
Minimum LSA arrival 1000 msecs
LSA group pacing timer 240 secs
Interface flood pacing timer 33 msecs
Retransmission pacing timer 66 msecs
Number of external LSA 0. Checksum Sum 0x000000
Number of opaque AS LSA 0. Checksum Sum 0x000000
Number of DCbitless external and opaque AS LSA 0
Number of DoNotAge external and opaque AS LSA 0
Number of areas in this router is 1. 1 normal 0 stub 0 nssa
Number of areas transit capable is 0
External flood list length 0
IETF NSF helper support enabled
Cisco NSF helper support enabled
Area 1
Number of interfaces in this area is 2
Area has no authentication
SPF algorithm last executed 08:35:56.788 ago
SPF algorithm executed 2 times
Area ranges are
Number of LSA 7. Checksum Sum 0x046CFF
Number of opaque link LSA 0. Checksum Sum 0x000000 Number of DCbitless LSA 0
Number of indication LSA 0
Number of DoNotAge LSA 0
Flood list length 0
In the above output, notice that SPF algorithm was run twice. This means there was a change in the network once after OSPF started.
Using show ip ospf interface command to verify and troubleshoot OSPF
One of the most important commands used to verify and troubleshoot OSPF is the show ip ospf interface command. It can be used to see information of all interfaces participating in OSPF or any specific interface. A sample output form RouterD is shown below:
RouterD#sh ip ospf interface
FastEthernet0/1 is up, line protocol is up
Internet Address 192.168.6.4/24, Area 2
Process ID 1, Router ID 192.168.6.4, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 192.168.7.6, Interface address 192.168.6.6
Backup Designated router (ID) 192.168.6.5, Interface address 192.168.6.5
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:06
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 2/2, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 3, maximum is 3
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 192.168.6.5 (Backup Designated Router)
Adjacent with neighbor 192.168.7.6 (Designated Router)
Suppress hello for 0 neighbor(s)
FastEthernet0/0 is up, line protocol is up
Internet Address 192.168.5.4/24, Area 2
Process ID 1, Router ID 192.168.6.4, Network Type BROADCAST, Cost: 10
Transmit Delay is 1 sec, State DROTHER, Priority 1
Designated Router (ID) 192.168.5.3, Interface address 192.168.5.3
Backup Designated router (ID) 192.168.6.5, Interface address 192.168.5.5
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:00
Supports Link-local Signaling (LLS)
Cisco NSF helper support enabled
IETF NSF helper support enabled
Index 1/1, flood queue length 0
Next 0x0(0)/0x0(0)
Last flood scan length is 1, maximum is 2
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 2, Adjacent neighbor count is 2
Adjacent with neighbor 192.168.5.3 (Designated Router)
Adjacent with neighbor 192.168.6.5 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
In the output of the show ip ospf interface command, you will get a lot of information regarding the interfaces participating in OSPF as well as the network segment each interface is attached to. The following information is of particular importance:
1. The Interface IP
2. Area that the interface belongs to
3. The Router ID
4. Network type
5. The DR and BDR IP address in that segment (in case of multi-access networks)
6. The hello and dead timers
7. Neighbors and Adjacency count
8. Reason of adjacency (in case of multi-access networks)
In the above output, notice that RouterD is not the DR or BDR for both the network segments it is connected to.
Using show ip ospf neighbor command to verify and troubleshoot OSPF
One of the most important parts of OSPF is the neighborship discovery and formation of adjacency. Hence the output from the show ip ospf neighbor command is very important. There are some variations in the output of this command and the best example is the output from RouterC because it consists of multiple types of interfaces. The output from RouterC is shown below:
RouterC#show ip ospf neighbor
Neighbor ID Pri State Dead Time Address Interface
192.168.3.2 0 FULL/ – 00:00:33 192.168.3.2 Serial0/0
192.168.6.4 1 FULL/DROTHER 00:00:33 192.168.5.4 FastEthernet0/1
192.168.6.5 1 FULL/BDR 00:00:31 192.168.5.5 FastEthernet0/1
The fields of the above output are discussed below:
1. Neighbor ID – This field lists the Router ID of all the neighbors discovered. Remember this is the Router ID of the neighbor and not the IP address of the interface by which the router is connected to this router.
2. Pri (Priority) – This is the interface priority of the neighbor. A priority of 0 is seen if the neighbor is manually configured with this priority or if the network between then neighbors is not a multi-access network.
3. State – This field indicates the state of adjacency. FULL indicates that a complete adjacency has been established with the neighbor and database has been exchanged. The second value indicates the type of adjacency. Possible values are DR (the adjacent router is a DR), BDR (the adjacent router is BDR), DOTHER (the adjacent router is a router in the network) and – which means that it’s an adjacency across a non-multi-access link. If the first value is stuck as 2WAY, this means that an adjacency has not been formed. Possible reason for this is that the neighbor is not a DR or BDR in a multi-access network. An adjacency stuck at any other state is reason for concern.
4. Dead Time – This field indicates the period after which the neighbor will be declared dead if a hello packet is not received.
5. Address – This field indicates the interface IP address of the neighbor that is connected to the same network as this router.
6. Interface – The interface towards which the neighbor can be reached.
Using show ip ospf database command to verify and troubleshoot OSPF
The show ip ospf database command shows two important things regarding the area a router is connect to – the number of routers in the area and the network links known in the area. The output is broken down by area. An example of the output from RouterC is given below:
RouterC#sh ip ospf database
OSPF Router with ID (192.168.5.3) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
192.168.3.2 192.168.3.2 1767 0x80000032 0x00D672 2
192.168.5.3 192.168.5.3 61 0x80000034 0x00F0CA 3
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
192.168.1.0 192.168.3.2 1767 0x80000032 0x0024C4
192.168.2.0 192.168.3.2 1767 0x80000032 0x00B43D
192.168.5.0 192.168.5.3 61 0x80000034 0x005DC2
192.168.6.0 192.168.5.3 61 0x80000033 0x00B85D
192.168.7.0 192.168.5.3 61 0x80000033 0x0012F8
Router Link States (Area 2)
Link ID ADV Router Age Seq# Checksum Link count
192.168.5.3 192.168.5.3 1305 0x80000036 0x0050DD 1
192.168.6.4 192.168.6.4 1584 0x80000038 0x00190D 2
192.168.6.5 192.168.6.5 1743 0x80000039 0x005CBA 2
192.168.7.6 192.168.7.6 78 0x80000035 0x00B6DC 2
Net Link States (Area 2)
Link ID ADV Router Age Seq# Checksum
192.168.5.3 192.168.5.3 1307 0x80000034 0x001CAA
192.168.6.6 192.168.7.6 1332 0x80000034 0x0003B5
Summary Net Link States (Area 2)
Link ID ADV Router Age Seq# Checksum
192.168.1.0 192.168.5.3 63 0x80000033 0x009014
192.168.2.0 192.168.5.3 63 0x80000033 0x00218C
192.168.3.0 192.168.5.3 63 0x80000033 0x009359
192.168.4.0 192.168.5.3 63 0x80000034 0x0068B8
You can see that routers available in area 0 and area 2 are shown along with links known in the area. ADV Router stands for advertising router and the field shows the router ID of the originating router for each link. Inter-area links will show as originating from the ABR.
Using debug ip ospf packet to verify and troubleshoot OSPF
Like EIGRP, OSPF packets can be seen entering and leaving a router. The command to see the packets is debug ip ospf packet. Ideally in a stable network you will only see the hello packets as shown below in the output from RouterC:
OSPF: rcv. v:2 t:1 l:52 rid:192.168.6.4
aid:0.0.0.2 chk:E35 aut:0 auk: from FastEthernet0/1
RouterC#
OSPF: rcv. v:2 t:1 l:52 rid:192.168.6.5
aid:0.0.0.2 chk:E35 aut:0 auk: from FastEthernet0/1
RouterC#
OSPF: rcv. v:2 t:1 l:48 rid:192.168.3.2
aid:0.0.0.0 chk:6344 aut:0 auk: from Serial0/0
RouterC#
OSPF: rcv. v:2 t:1 l:52 rid:192.168.6.4
aid:0.0.0.2 chk:E35 aut:0 auk: from FastEthernet0/1
RouterC#
OSPF: rcv. v:2 t:1 l:52 rid:192.168.6.5
aid:0.0.0.2 chk:E35 aut:0 auk: from FastEthernet0/1
RouterC#
OSPF: rcv. v:2 t:1 l:48 rid:192.168.3.2
aid:0.0.0.0 chk:6344 aut:0 auk: from Serial0/0
The above output shows the hello packets received from the three neighbors on RouterC.
Using debug ip ospf hello to verify and troubleshoot OSPF
While the debug ip ospf packet command shows all packets, the show ip ospf hello command can be used to specifically look at hello messages sent and received on a router. This can useful to troubleshoot neighborship and adjacency problems. Output from RouterC is shown below:
RouterC#
OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 192.168.3.3
OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.4.3
OSPF: Send hello to 224.0.0.5 area 2 on FastEthernet0/1 from 192.168.5.3
OSPF: Rcv hello from 192.168.6.5 area 2 from FastEthernet0/1 192.168.5.5
OSPF: End of hello processing
OSPF: Rcv hello from 192.168.3.2 area 0 from Serial0/0 192.168.3.2
OSPF: End of hello processing
RouterC#
OSPF: Rcv hello from 192.168.6.4 area 2 from FastEthernet0/1 192.168.5.4
OSPF: End of hello processing
RouterC#
OSPF: Send hello to 224.0.0.5 area 0 on Serial0/0 from 192.168.3.3
OSPF: Send hello to 224.0.0.5 area 0 on FastEthernet0/0 from 192.168.4.3
RouterC#
OSPF: Rcv hello from 192.168.3.2 area 0 from Serial0/0 192.168.3.2
OSPF: End of hello processing
OSPF: Send hello to 224.0.0.5 area 2 on FastEthernet0/1 from 192.168.5.3
OSPF: Rcv hello from 192.168.6.5 area 2 from FastEthernet0/1 192.168.5.5
OSPF: End of hello processing
RouterC#
OSPF: Rcv hello from 192.168.6.4 area 2 from FastEthernet0/1 192.168.5.4
OSPF: End of hello processing
In the above output you can see that RouterC is sending hello packets out all its interfaces and is receiving hello packets back from all neighbors. If there is a problem with hello packets such as an interval mismatch, the debug will show that error.
Using debug ip ospf adj to verify and troubleshoot OSPF
As mentioned earlier, adjacency formation is the most important part of OSPF operation and most problems occur at that stage. The output from debug ip ospf adj helps identify problems related to an adjacency. Since there are no adjacency related events in a stable network, I cleared the ospf process on RouterB to generate the following output on RouterC:
RouterC#
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 76 LSA count 1
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 84 LSA count 2
OSPF: Cannot see ourself in hello from 192.168.3.2 on Serial0/0, state INIT
OSPF: 2 Way Communication to 192.168.3.2 on Serial0/0, state 2WAY
OSPF: Send DBD to 192.168.3.2 on Serial0/0 seq 0x685 opt 0x52 flag 0x7 len 32
OSPF: Rcv DBD from 192.168.3.2 on Serial0/0 seq 0x23C7 opt 0x52 flag 0x7 len 32 mtu 1500 state EXSTART
OSPF: First DBD and we are not SLAVE
OSPF: Rcv DBD from 192.168.3.2 on Serial0/0 seq 0x685 opt 0x52 flag 0x0 len 32 mtu 1500 state EXSTART
OSPF: NBR Negotiation Done. We are the MASTER
OSPF: Send DBD to 192.168.3.2 on Serial0/0 seq 0x686 opt 0x52 flag 0x3 len 112
OSPF: Rcv DBD from 192.168.3.2 on Serial0/0 seq 0x686 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
OSPF: Send DBD to 192.168.3.2 on Serial0/0 seq 0x687 opt 0x52 flag 0x1 len 32
OSPF: Rcv LS REQ from 192.168.3.2 on Serial0/0 length 72 LSA count 4
OSPF:
RouterC#Send UPD to 192.168.3.2 on Serial0/0 length 148 LSA count 4
OSPF: Rcv DBD from 192.168.3.2 on Serial0/0 seq 0x687 opt 0x52 flag 0x0 len 32 mtu 1500 state EXCHANGE
OSPF: Exchange Done with 192.168.3.2 on Serial0/0
OSPF: Synchronized with 192.168.3.2 on Serial0/0, state FULL
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 76 LSA count 1
RouterC#
RouterC#
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 56 LSA count 1
OSPF: Send UPD to 192.168.3.2 on Serial0/0 length 32 LSA count 1
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 56 LSA count 1
OSPF: Send UPD to 192.168.3.2 on Serial0/0 length 32 LSA count 1
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 76 LSA count 1
OSPF: Send UPD to 192.168.3.2 on Serial0/0 length 52 LSA count 1
RouterC#
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 84 LSA count 2
OSPF: Send UPD to 192.168.3.2 on Serial0/0 length 60 LSA count 2
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 76 LSA count 1
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 56 LSA count 1
OSPF: Rcv LS UPD from 192.168.3.2 on Serial0/0 length 56 LSA count 1
The above output shows the transition of the adjacency through various stages – 2WAY, EXSTART, EXCHANGE and finally FULL. While these states are out of scope of
CNA, the output gives you an idea of how an adjacency is formed. In the EXCHANGE state, the database is synchronized and then the FULL state is reached. Any problems during any of these states will be seen in this debug.
Posts
0 comments:
Post a Comment