Chapter 8. Troubleshooting OSPFv2
This chapter covers the following topics:
Troubleshooting OSPFv2 Neighbor Adjacencies: This section covers the reasons OSPFv2 neighbor adjacencies sometimes do not form and how to identify them.
Troubleshooting OSPFv2 Routes: This section covers the reasons OSPFv2 routes might be missing from the link-state database (LSDB) and routing table and how to determine why they are missing.
Troubleshooting Miscellaneous OSPFv2 Issues: This section focuses on tracking link-state advertisements (LSAs) through the network, route summarization, discontiguous areas, load balancing, and default routes.
OSPFv2 Trouble Tickets: This section presents three trouble tickets that demonstrate how to use a structured troubleshooting process to solve a reported problem.
The Open Shortest Path First (OSPF) dynamic routing protocol is a link-state routing protocol that uses Dijkstra’s shortest path first (SPF) algorithm. It is an extremely scalable routing protocol because of its hierarchical design. OSPF can route for both IPv4 and IPv6 protocols. This chapter focuses on troubleshooting OSPFv2; Chapters 9, “OSPFv3,” and 10, “Troubleshooting OSPFv3,” focus on OSPFv3.
Before any routes are exchanged between OSPF routers on the same LAN or across a WAN, an OSPF neighbor relationship must be formed. There are many reasons a neighbor relationship may not form, and as a troubleshooter, you need to be aware of them. This chapter delves deeply into these reasons and gives you the tools needed to identify them and successfully solve neighbor issues.
Once neighbor relationships are formed, neighboring routers exchange OSPF LSAs, which contain information about routes. In various cases, routes may end up missing, and you need to be able to determine why the routes are missing. This chapter discusses the various ways that OSPF routes could go missing, how to identify the reasons they are missing, and how to solve route-related issues.
In this chapter, you will also learn how to troubleshoot issues related to load balancing, summarization, and discontiguous areas.
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 8-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quiz Questions.”
Table 8-1 “Do I Know This Already?” Foundation Topics Section-to-Question Mapping
Foundation Topics Section |
Questions |
Troubleshooting OSPFv2 Neighbor Adjacencies |
1–5, 7 |
Troubleshooting OSPFv2 Routes |
6, 8 |
Troubleshooting Miscellaneous OSPFv2 Issues |
9, 10 |
1. Which of the following prevent OSPF neighbor relationships from forming? (Choose two.)
Mismatched timers
Mismatched area numbers
Duplicate router IDs
Wrong designated router elected
2. In which OSPF states are you likely to find routers that have an MTU mismatch? (Choose two.)
Init
2-Way
ExStart
Exchange
3. Which OSPFv2 command enables you to verify the hello interval and the dead interval?
show ip protocols
show ip ospf interface
show ip ospf neighbor
show ip ospf database
4. Which OSPFv2 debug command enables you to verify whether area numbers are mismatched?
debug ip ospf hello
debug ip ospf adj
debug ip ospf packet
debug ip ospf events
5. Which OSPF network type is the default on LAN interfaces?
Broadcast
NBMA
Point-to-point
Point-to-multipoint
6. Which LSA type describes routes outside the area but still within the OSPF routing domain (interarea routes)?
1
2
3
5
7. Which of the following can prevent an OSPF neighborship from being formed?
A distribute list applied inbound
A distribute list applied outbound
An ACL applied inbound
An ACL applied outbound
8. OSPF neighborships have been successfully formed throughout the entire routing domain. Which of the following are reasons any router may be missing routes in the local LSDB or the local routing table? (Choose two.)
The missing route’s network interface has been configured as passive.
There are duplicate router IDs in the routing domain.
There is an outbound distribute list configured.
The spoke is the DR in a hub and spoke topology.
9. Which command is used to redistribute a static default route into OSPF?
redistribute static
redistribute ospf 1 subnets
default-information originate
ip route 0.0.0.0 0.0.0.0 110
10. Which of the following are reasons a virtual link might not be forming? (Choose two.)
The router’s interface IP address is being used in the virtual-link command.
The local area ID is being used in the virtual-link command.
The router ID is being used in the virtual-link command.
The transit area ID is being used in the virtual-link command.
Foundation Topics
Troubleshooting OSPFv2 Neighbor Adjacencies
OSPF establishes neighbor relationships by sending hello packets out interfaces participating in the OSPF process. To enable the OSPF process on an interface and place it in an OSPF area, you use the network ip_address wildcard_mask area area_id command in router OSPF configuration mode or the ip ospf process_id area area_id command in interface configuration mode. For example, the following network ip_address wildcard_mask area area_id command enables OSPF on all interfaces with an IP address from 10.1.1.0 through 10.1.1.255 and places them in Area 0: network 10.1.1.0 0.0.0.255 area 0. The following interface configuration command enables the OSPF process on the interface and places it in Area 51: ip ospf 1 area 51. Because there are two different ways to enable OSPFv2 on an interface, you must be very careful when troubleshooting neighbor adjacencies so that you are not led down the wrong path, thinking that the OSPF process was not enabled on an interface when in fact it was. You need to check both places.
This section focuses on the reasons an OSPF neighbor relationship might not form and how to identify them during the troubleshooting process.
To verify OSPFv2 neighbors, you use the show ip ospf neighbor command. Example 8-1 shows sample output of the show ip ospf neighbor command. It lists the neighbor ID, which is the router ID (RID) of the neighbor, the priority of the neighbor for the designated router/backup designated router (DR/BDR) election process, the state of the neighbor (covered shortly), and whether the neighbor is a DR, BDR, or DROTHER. In addition, it displays the dead time, which is how long the local router waits until it declares the neighbor down if it does not hear another hello packet within that time (the default is 40 seconds on a LAN). You can also see the neighbor’s interface IP address from which the hello packet was sent and the local router interface used to reach that neighbor.
Example 8-1 Verifying OSPF Neighbors with show ip ospf neighbor
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.1.23.2 1 FULL/BDR 00:00:37 10.1.12.2 GigabitEthernet1/0
When an OSPF neighbor adjacency is successfully formed, you receive a syslog message similar to the following:
%OSPF-5-ADJCHG: Process 1, Nbr 10.1.23.2 on GigabitEthernet1/0 from LOADING to FULL, Loading Done
The following are some of the reasons an OSPFv2 neighbor relationship might not form:
Interface is down: The interface must be up/up.
Interface not running the OSPF process: If the interface is not enabled for OSPF, it does not send hello packets or form adjacencies.
Mismatched timers: Hello and dead timers must match between neighbors.
Mismatched area numbers: The two ends of a link must be in the same OSPF area.
Mismatched area type: In addition to a normal OSPF area type, an area type could be either a stub area or a not-so-stubby area (NSSA). The routers must agree on the type of area they are in.
Different subnets: Neighbors must be in the same subnet.
Passive interface: The passive interface feature suppresses the sending and receiving of hello packets while still allowing the interface’s network to be advertised.
Mismatched authentication information: If one OSPF interface is configured for authentication, the OSPF interface at the other end of the link must be configured with matching authentication information.
ACLs: An ACL may be denying packets to the OSPF multicast address 224.0.0.5.
MTU mismatch: The maximum transmission unit of neighboring interfaces must match.
Duplicate router IDs: Router IDs must be unique.
Mismatched network types: Based on the OSPF network type characteristics and default values, two neighbors configured with a different OSPF network type might not form an adjacency.
Adjacencies are not established upon the immediate receipt of hello messages. Rather, an adjacency transitions through the various states described in Table 8-2.
Table 8-2 Adjacency States
State |
Description |
Down |
This state indicates that no hellos have been received from a neighbor. |
Attempt |
This state occurs after a router sends a unicast hello (as opposed to a multicast hello) to a configured neighbor and has not yet received a hello from that neighbor. |
Init |
This state occurs on a router that has received a hello message from its neighbor; however, the OSPF RID of the receiving router was not contained in the hello message. If a router remains in this state for a long period, something is probably preventing that router from correctly receiving hello packets from the neighboring router. |
2-Way |
This state occurs when two OSPF routers have received hello messages from each other, and each router saw its own OSPF RID in the hello message it received. The 2-Way state is an acceptable state to stay in between DROTHERs on an Ethernet LAN. |
ExStart |
This state occurs when the routers forming a full neighbor adjacency decide who will send their routing information first. This is accomplished using the RID. The router with the higher RID becomes the master, and the other one becomes the slave. The master sends the routing information first. In a multi-access network, the DR and BDR have to be determined before this state starts. However, the DR does not have to be the master because each master/slave election is on a per-neighbor basis. If a router remains in this state for a long period, a maximum transmission unit (MTU) mismatch could exist between the neighboring routers, or a duplicate OSPF RID might exist. |
Exchange |
This state occurs when the two routers forming an adjacency send one another database descriptor (DBD) packets containing information about a router’s link-state database. Each router compares the DBD packets received from the other router to identify missing entries in its own database. If a router remains in this state for a long period, an MTU mismatch could exist between the neighboring routers. |
Loading |
Based on the missing link-state database entries identified in the Exchange state, the Loading state occurs when each neighboring router requests the other router to send those missing entries. If a router remains in this state for a long period, a packet might have been corrupted, or a router might have a memory issue. Alternatively, it is possible that such a condition could result from the neighboring routers having an MTU mismatch. |
Full |
This state indicates that the neighboring OSPF routers have successfully exchanged their link-state information with one another, and an adjacency has been formed. |
When an OSPF neighbor relationship does not form, the neighbor is not listed in the neighbor table. Therefore, you need the assistance of an accurate physical and logical network diagram and the show cdp neighbors command to verify who should be the neighbors.
When troubleshooting OSPF adjacencies, you need to be aware of how to verify the parameters associated with each of the reasons listed earlier. Let’s look at them individually.
Interface Is Down
The interface must be up/up if you plan on forming an OSPF neighbor adjacency. As you learned in previous studies such as CCNA and ENCORE, you can verify the status of an interface with the show ip interface brief command.
Interface Not Running the OSPF Process
If the router OSPF configuration mode network ip_address wildcard_mask area area_id command or the ip ospf process_id area area_id interface command is misconfigured, OSPF may not be enabled on the proper interfaces. As a result, hello packets are not sent, and neighbor relationships are not formed. You also must specify the OSPF area the interface belongs to. Therefore, if the command is correct, except for the area ID, the interface is participating in the OSPF process but in the wrong area. This prevents a neighbor relationship from forming as well. You can verify which interfaces are participating in the OSPF process by using the command show ip ospf interface brief, as shown in Example 8-2. In this example, two interfaces are participating in OSPF process 1. They are both in Area 1 and are the designated router interfaces for the multi-access networks. You can also verify the IP addresses and masks of the interfaces, along with the number of full neighbor relationships formed out the interface compared to the total number of neighbors out the interface.
Example 8-2 Verifying OSPF Interfaces with show ip ospf interface brief
R1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Gi0/0 1 1 10.1.1.1/24 1 DR 0/0 Gi1/0 1 1 10.1.12.1/24 1 DR 1/1
The output of show ip protocols displays the network ip_address wildcard_mask area area_id statements as well as the interfaces that were enabled for OSPF with the ip ospf process_id area area_id interface command. Focus on the highlighted text in Example 8-3. Notice that it states Routing for Networks. Those are not the networks you are routing for. You are routing for the networks associated with the interfaces OSPF will be enabled on, based on the network area statement. In this case, 10.1.1.1 0.0.0.0 area 1 really means “locate the interface with this IP address and enable it for the OSPF process and place it in Area 1.” In addition, you can see which interfaces were explicitly configured to participate in the OSPF process by using the ip ospf process_id area area_id interface configuration mode command. In this example, GigabitEthernet1/0 was enabled for OSPF with the ip ospf 1 area 1 command, and GigabitEthernet0/0 was enabled for OSPF with the network 10.1.1.1 0.0.0.0 area 1 router OSPF configuration mode command.
Example 8-3 Verifying OSPF-Enabled Interfaces with show ip protocols
R1# show ip protocols *** IP Routing is NSF aware *** 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 10.1.12.1 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 10.1.1.1 0.0.0.0 area 1 Routing on Interfaces Configured Explicitly (Area 1): GigabitEthernet1/0 Routing Information Sources: Gateway Distance Last Update 10.1.23.2 110 00:24:22 Distance: (default is 110)
The network ip_address wildcard_mask area area_id command is extremely important, as is the ip ospf process_id area area_id command. If either of these commands is misconfigured, interfaces that should be participating in the OSPF process might not be, and interfaces that should not be participating in the OSPF process might be. In addition, it is possible that interfaces might be participating but in the wrong area, preventing neighbor relationships from forming. Therefore, you should be able to recognize issues related to both of these commands.
Mismatched Timers
Unlike with Enhanced Interior Gateway Routing Protocol (EIGRP), with OSPF, timers do have to match between neighbors in order for neighbor adjacencies to form. The hello timer defaults to 10 seconds for broadcast and point-to-point network types and 30 seconds for nonbroadcast and point-to-multipoint network types. The dead timer defaults to 40 seconds for broadcast and point-to-point network types and 120 seconds for nonbroadcast and point-to-multipoint network types. To verify the current timers associated with an OSPF interface, issue the show ip ospf interface interface_type interface_number command, as shown in Example 8-4. In this example, GigabitEthernet1/0 is using the default Hello timer of 10 and Dead timer of 40. When determining whether timers match, use the spot-the-difference method between the outputs on the two routers.
Example 8-4 Displaying OSPF Interface Timers on R1 GigabitEthernet1/0
R1# show ip ospf interface gigabitEthernet 1/0 GigabitEthernet1/0 is up, line protocol is up Internet Address 10.1.12.1/24, Area 1, Attached via Interface Enable Process ID 1, Router ID 10.1.12.1, Network Type BROADCAST, Cost: 1 Topology-MTID Cost Disabled Shutdown Topology Name 0 1 no no Base Enabled by interface config, including secondary ip addresses Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 10.1.12.1, Interface address 10.1.12.1 Backup Designated router (ID) 10.1.23.2, Interface address 10.1.12.2 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:04 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 1 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 1, Adjacent neighbor count is 1 Adjacent with neighbor 10.1.23.2 (Backup Designated Router) Suppress hello for 0 neighbor(s)
You can use the debug ip ospf hello command when troubleshooting adjacencies to reveal mismatched timers, as shown in Example 8-5. In this example, the packet received (R) has a dead timer of 44 and a hello timer of 11. The local device (C) has a dead timer of 40 and a hello timer of 10.
Example 8-5 Using debug ip ospf hello to Identify Mismatched Timers
R1# debug ip ospf hello
OSPF hello debugging is on
R1#
OSPF-1 HELLO Gi1/0: Rcv hello from 2.2.2.2 area 1 10.1.12.2
OSPF-1 HELLO Gi1/0: Mismatched hello parameters from 10.1.12.2
OSPF-1 HELLO Gi1/0: Dead R 44 C 40, Hello R 11 C 10 Mask R 255.255.255.0 C
255.255.255.0
R1#
Mismatched Area Numbers
Because OSPF uses the concept of areas, it is an extremely scalable dynamic routing protocol. For OSPF routers to form neighbor adjacencies, their neighboring interfaces must be in the same area. You can verify the area an OSPF interface is part of by using the show ip ospf interface interface_type interface_number command, as shown in Example 8-6, or the show ip ospf interface brief command, as shown in Example 8-7. When determining whether area IDs match, you can use the spot-the-difference method between the outputs on the two routers.
Example 8-6 Displaying the OSPF Interface Area by Using the show ip ospf interface interface_type interface_number Command
R1# show ip ospf interface gigabitEthernet 1/0
GigabitEthernet1/0 is up, line protocol is up
Internet Address 10.1.12.1/24, Area 1, Attached via Interface Enable
Process ID 1, Router ID 10.1.12.1, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State DR, Priority 1
Designated Router (ID) 10.1.12.1, Interface address 10.1.12.1
Backup Designated router (ID) 10.1.23.2, Interface address 10.1.12.2
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:04
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 1
Last flood scan time is 0 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.1.23.2 (Backup Designated Router)
Suppress hello for 0 neighbor(s)
Example 8-7 Displaying the OSPF Interface Area by Using the show ip ospf interface brief Command
R1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Gi1/0 1 1 10.1.12.1/24 1 DR 1/1
You can use the debug ip ospf adj command when troubleshooting adjacencies to find mismatched area numbers, as shown in Example 8-8. In this example, the packet received has an area ID of 1, and the local interface is participating in Area 2.
Example 8-8 Using debug ip ospf adj to Identify Mismatched Area Numbers
R1# debug ip ospf adj
OSPF adjacency debugging is on
R1#
OSPF-1 ADJ Gi1/0: Rcv pkt from 10.1.12.2, area 0.0.0.2, mismatched area 0.0.0.1 in
the header
R1# u all
All possible debugging has been turned off
Mismatched Area Type
The default OSPF area type is classified as a normal area. However, you can convert a normal area into a stub area or NSSA area to control the types of link-state advertisements (LSAs) that will be sent into the area from an area border router (ABR). For routers within an area to form adjacencies, they must agree on the area type. Within the hello packet, a stub area flag is designed to indicate the type of area the neighbor is in. You can verify the types of areas connected to a router by using the show ip protocols command. However, it does not tell you which area is which type. In Example 8-9, which displays the output of show ip protocols, there is only one area (Area 1); therefore, you can deduce that it is the stub area. However, if there is a router with multiple areas connected to it, you can verify the areas and their type by using the show ip ospf command, as shown in Example 8-9. In this example, any interface in Area 1 is in a stub area.
Example 8-9 Determining the Type of OSPF Areas
R1# show ip protocols *** IP Routing is NSF aware *** 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 10.1.12.1 Number of areas in this router is 1. 0 normal 1 stub 0 nssa Maximum path: 4 Routing for Networks: 10.1.1.1 0.0.0.0 area 1 Routing on Interfaces Configured Explicitly (Area 1): GigabitEthernet1/0 Routing Information Sources: Gateway Distance Last Update 10.1.23.2 110 00:04:42 Distance: (default is 110) R1# show ip ospf Routing Process "ospf 1" with ID 10.1.12.1 Start time: 02:23:19.824, Time elapsed: 02:08:52.184 ...output omitted... Reference bandwidth unit is 100 mbps Area 1 Number of interfaces in this area is 2 It is a stub area Area has no authentication SPF algorithm last executed 00:05:46.800 ago ...output omitted...
You can use the debug ip ospf hello command when troubleshooting adjacencies to find mismatched area types, as shown in Example 8-10. In this example, you can see that the packet received has a mismatched Stub/Transit area option bit.
Example 8-10 Using debug ip ospf hello to Identify Mismatched Area Types
R1# debug ip ospf hello
OSPF hello debugging is on
R1#
OSPF-1 HELLO Gi1/0: Rcv hello from 2.2.2.2 area 1 10.1.12.2
OSPF-1 HELLO Gi1/0: Hello from 10.1.12.2 with mismatched Stub/Transit area option bit
R1#
Different Subnets
To form an OSPF neighbor adjacency, the router interfaces must be on the same subnet. You can verify this in many ways. The simplest is to look at the interface configuration in the running configuration with the show running-config interface interface_type interface_number command. Example 8-11 shows the configuration of GigabitEthernet1/0 on R1 and GigabitEthernet0/0 on R2. Are they in the same subnet? Yes! Based on the IP address and the subnet mask, they are both in the 10.1.12.0/24 subnet.
Example 8-11 Verifying That Neighboring Interfaces Are on the Same Subnet
R1# show running-config interface gigabitEthernet 1/0 Building configuration... Current configuration : 108 bytes ! interface GigabitEthernet1/0 ip address 10.1.12.1 255.255.255.0 ip ospf 1 area 1 negotiation auto end R2# show running-config interface gigabitEthernet 0/0 Building configuration... Current configuration : 132 bytes ! interface GigabitEthernet0/0 ip address 10.1.12.2 255.255.255.0 negotiation auto end
Passive Interface
The passive interface feature is important for all organizations. It does two things: reduces the OSPF-related traffic on a network and improves OSPF security.
The passive interface feature turns off the sending and receiving of OSPF packets on an interface while still allowing the interface’s network ID to be injected into the OSPF process and advertised to other OSPF neighbors. This ensures that rogue routers that attach to the network will not be able to form adjacencies with your legitimate router on that interface since your router is not sending or receiving OSPF packets on the interface. However, if you configure the wrong interface as passive, a legitimate OSPF neighbor relationship is not formed. As shown in the show ip protocols output in Example 8-12, GigabitEthernet0/0 is a passive interface. If there are no passive interfaces, this section does not appear in the output of show ip protocols.
Example 8-12 Verifying Passive Interfaces with show ip protocols
R1# show ip protocols *** IP Routing is NSF aware *** 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 10.1.12.1 Number of areas in this router is 1. 0 normal 1 stub 0 nssa Maximum path: 4 Routing for Networks: 10.1.1.1 0.0.0.0 area 1 Routing on Interfaces Configured Explicitly (Area 1): GigabitEthernet1/0 Passive Interface(s): GigabitEthernet0/0 Routing Information Sources: Gateway Distance Last Update 10.1.23.2 110 00:00:03 Distance: (default is 110)
Mismatched Authentication Information
Authentication is used to ensure that your OSPF routers form neighbor relationships only with legitimate routers and that they accept OSPF packets only from legitimate routers. Therefore, if authentication is implemented, both routers must agree on the settings for a neighbor relationship to form. With authentication, you can use the spot-the-difference method when troubleshooting. OSPF supports three types of authentication:
Null: Known as type 0 and means no authentication
Plaintext: Known as type 1 and sends credentials in plaintext
MD5: Known as type 2 and sends a hash
OSPF authentication can be enabled on an interface-by-interface basis or for all interfaces in the area at the same time. Knowing which commands to use to verify these different authentication configuration options is important. To verify whether authentication has been enabled for the entire area on a router, you use the show ip ospf command, as shown in Example 8-13. However, with Message Digest 5 (MD5) authentication, you still have to verify the key ID that is being used on an interface-by-interface basis by using the show ip ospf interface interface_type interface_number command, as shown in Example 8-14. In addition, you must verify the case-sensitive key string that is being used by using the show running-config interface interface_type interface_number command.
Example 8-13 Verifying OSPF Area Authentication
R1# show ip ospf
Routing Process "ospf 1" with ID 10.1.12.1
Start time: 02:23:19.824, Time elapsed: 02:46:34.488
...output omitted...
Reference bandwidth unit is 100 mbps
Area 1
Number of interfaces in this area is 2
It is a stub area
Area has message digest authentication
SPF algorithm last executed 00:25:12.220 ago
...output omitted...
Example 8-14 Verifying the OSPF Authentication Key
R1# show ip ospf interface gigabitEthernet 1/0 GigabitEthernet1/0 is up, line protocol is up Internet Address 10.1.12.1/24, Area 1, Attached via Interface Enable ...output omitted... Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Message digest authentication enabled Youngest key id is 1
You can use the debug ip ospf adj command when troubleshooting adjacencies to find mismatched authentication information, as shown in Example 8-15. In this example, the packet received is using null authentication (type 0), and the local router is using plaintext authentication (type 1).
Example 8-15 Using debug ip ospf adj to Identify Mismatched Authentication Information
R1# debug ip ospf adj
OSPF adjacency debugging is on
R1#
OSPF-1 ADJ Gi1/0: Rcv pkt from 10.1.12.2 : Mismatched Authentication type. Input
packet specified type 0, we use type 1
R1#
ACLs
Access control lists (ACLs) are extremely powerful. How they are implemented determines what they control in a network. If an ACL is applied to an interface, and the ACL is not permitting OSPF packets, a neighbor relationship does not form. To determine whether an ACL is applied to an interface, use the show ip interface interface_type interface_number command, as shown in Example 8-16. Notice that ACL 100 is applied inbound on interface GigabitEthernet1/0. To verify the ACL 100 entries, issue the command show access-lists 100, as shown in Example 8-17. In this case, you can see that ACL 100 is denying OSPF traffic, which prevents a neighbor relationship from forming.
Note that outbound ACLs do not affect OSPF packets. Therefore, if there is an outbound ACL configured on an interface and a neighbor adjacency is not forming, the ACL is not the problem even though it might be denying OSPF packets because the outbound ACL does not apply to OSPF packets generated on the local router.
Example 8-16 Verifying ACLs Applied to Interfaces
R1# show ip interface gig 1/0 GigabitEthernet1/0 is up, line protocol is up Internet address is 10.1.12.1/24 Broadcast address is 255.255.255.255 Address determined by setup command MTU is 1500 bytes Helper address is not set Directed broadcast forwarding is disabled Multicast reserved groups joined: 224.0.0.10 Outgoing access list is not set Inbound access list is 100 Proxy ARP is enabled Local Proxy ARP is disabled Security level is default Split horizon is enabled
Example 8-17 Verifying ACL Entries
R1# show access-lists 100
Extended IP access list 100
10 deny ospf any any (62 matches)
20 permit ip any any
MTU Mismatch
For OSPF routers to become neighbors and achieve the full adjacency state, the interface of each router forming the adjacency must have exactly the same MTU. If they don’t, the routers can see each other but get stuck in the ExStart/Exchange states. In Example 8-18, the output of show ip ospf neighbor indicates that R1 is stuck in the Exchange state, and that R2 is stuck in the ExStart state.
Example 8-18 Symptoms of an MTU Mismatch (Stuck in ExStart/Exchange)
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.1.23.2 1 EXCHANGE/DR 00:00:38 10.1.12.2 GigabitEthernet1/0 R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.1.12.1 1 EXSTART/BDR 00:00:37 10.1.12.1 GigabitEthernet0/0
In the output of show ip ospf interface brief, you can see the Nbrs F/C column without expected values. In Example 8-19, the output shows 0/1 in the Nbrs F/C column, which indicates that there is one neighbor out the interface, but there are zero full adjacencies.
Example 8-19 Symptoms of an MTU Mismatch (Nbrs Column Values Do Not Match)
R1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Gi1/0 1 1 10.1.12.1/24 1 BDR 0/1 Gi0/0 1 1 10.1.1.1/24 1 DR 0/0
To verify the MTU configured on an interface, issue the show run interface interface_type interface_number command. As shown in Example 8-20, the MTU of GigabitEthernet1/0 on R1 is 1476, and because nothing is listed in the GigabitEthernet0/0 configuration of R2, it is using the default value, 1500.
Example 8-20 Verifying the MTU of an Interface
R1# show run interface gigabitEthernet 1/0
Building configuration...
Current configuration : 195 bytes
!
interface GigabitEthernet1/0
ip address 10.1.12.1 255.255.255.0
ip mtu 1476
ip ospf authentication-key CISCO
ip ospf message-digest-key 1 md5 CISCO
ip ospf 1 area 1
negotiation auto
end
R2# show run interface gigabitEthernet 0/0
Building configuration...
Current configuration : 211 bytes
!
interface GigabitEthernet0/0
ip address 10.1.12.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
negotiation auto
end
To solve this issue, you can either manually modify the MTU values of the interfaces so that they match, or you can use the ip ospf mtu-ignore interface configuration command, which stops OSPF from comparing the MTU when trying to form an adjacency.
Duplicate Router IDs
RIDs must be unique for many reasons. One of the reasons is that a neighbor relationship does not form between two routers if they have the same RID. When a duplicate RID exists, you receive a syslog message similar to the following:
%OSPF-4-DUP_RTRID_NBR: OSPF detected duplicate router-id 10.1.23.2 from 10.1.12.2 on interface GigabitEthernet1/0
To verify the RID of an OSPF router, you use the show ip protocols command, as shown in Example 8-21. However, almost all OSPF show commands display the RID in their output, so you can verify it any way you like. In Example 8-21, the output of show ip protocols indicates that the RID of R1 is 10.1.23.2. If you manually change the RID with the router-id command in router OSPF configuration mode, you must reset the OSPF process by using the clear ip ospf process command in order for it to take effect.
Example 8-21 Verifying an OSPF RID
R1# show ip protocols
*** IP Routing is NSF aware ***
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 10.1.23.2
Number of areas in this router is 1. 0 normal 1 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.1.1.1 0.0.0.0 area 1
Routing on Interfaces Configured Explicitly (Area 1):
GigabitEthernet1/0
Passive Interface(s):
Ethernet0/0
GigabitEthernet0/0
Routing Information Sources:
Gateway Distance Last Update
10.1.23.2 110 00:05:31
Distance: (default is 110)
Mismatched Network Types
OSPF supports multiple network types. Different network types have different default values. Therefore, if two OSPF routers that are trying to form a neighbor adjacency are configured with noncompatible network types, a neighbor relationship does not form. For example, if the network type is Broadcast on R1’s interface and NBMA on R2’s interface, the timers do not match, and the adjacency does not form. Table 8-3 lists the OSPF network types and their characteristics.
Table 8-3 OSPF Network Types and Characteristics
Type |
Default |
Neighbors |
DR/BDR |
Timers |
Broadcast |
Default on LAN interfaces |
Discovered automatically |
DR and BDR elected automatically |
Hello: 10 Dead: 40 |
NBMA (nonbroadcast) |
Default on Frame Relay main and point-to-multipoint interfaces |
Statically configured |
DR must be manually configured on the hub router |
Hello: 30 Dead: 120 |
Point-to-point |
Default on point-to-point serial and point-to-point Frame Relay subinterfaces |
Discovered automatically |
No DR or BDR |
Hello: 10 Dead: 40 |
Point-to-multipoint |
(Not a default) Optimal for hub-and-spoke topologies (Frame Relay) |
Discovered automatically |
No DR or BDR |
Hello: 30 Dead: 120 |
Point-to-multipoint nonbroadcast |
(Not a default) Optimal for hub-and-spoke topologies (Frame Relay) that do not support broadcast or multicast traffic |
Statically Configured |
No DR or BDR |
Hello: 30 Dead: 120 |
To determine the network type associated with an OSPF-enabled interface, you can issue the command show ip ospf interface interface_type interface_number. In Example 8-22, R1’s interface GigabitEthernet 1/0 is using the OSPF network type Broadcast. You can use the spot-the-difference troubleshooting method to determine whether the network types match.
Example 8-22 Verifying OSPF Network Type
R1# show ip ospf interface gigabitEthernet 1/0
GigabitEthernet1/0 is up, line protocol is up
Internet Address 10.1.12.1/24, Area 1, Attached via Interface Enable
Process ID 1, Router ID 10.1.12.1, Network Type BROADCAST, Cost: 1
Topology-MTID Cost Disabled Shutdown Topology Name
0 1 no no Base
Enabled by interface config, including secondary ip addresses
Transmit Delay is 1 sec, State BDR, Priority 1
Designated Router (ID) 10.1.23.2, Interface address 10.1.12.2
Backup Designated router (ID) 10.1.12.1, Interface address 10.1.12.1
Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
oob-resync timeout 40
Hello due in 00:00:07
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 1
Last flood scan time is 4 msec, maximum is 4 msec
Neighbor Count is 1, Adjacent neighbor count is 1
Adjacent with neighbor 10.1.23.2 (Designated Router)
Suppress hello for 0 neighbor(s)
Message digest authentication enabled
Youngest key id is 1
Troubleshooting OSPFv2 Routes
OSPF routers receive LSAs from every router within the same area, meaning they learn about routes directly from the source within the same area. As a result, the LSAs must be flooded through the area. This is mandatory because every router in an area must have exactly the same link-state database (LSDB) for that area. This makes troubleshooting missing OSPF routes more difficult than with distance vector routing protocols because it is harder to follow the path, especially in a multi-area OSPF domain.
This section examines the reasons OSPF routes might be missing and how to determine the reason a route is missing.
As discussed earlier, neighbor relationships are the foundation of OSPF information sharing. If you have no neighbors, you will not learn any routes. So, besides the lack of a neighbor, what would be reasons for missing routes in an OSPF network?
Following is a list of some common reasons OSPF routes might be missing either from the LSDB or the routing table:
Interface not running the OSPF process: If the interface is not participating in the OSPF process, the network the interface is part of is not injected into the OSPF process and is therefore not advertised to neighbors.
Better source of information: If exactly the same network is learned from a more reliable source, it is used instead of the OSPF-learned information.
Route filtering: A filter might be preventing a route from being installed in the routing table.
Stub area configuration: If the wrong type of stub area is chosen, you might be receiving a default route instead of the actual route.
Interface is shut down: The OSPF-enabled interface must be up/up for the network associated with the interface to be advertised.
Wrong designated router elected: In a hub-and-spoke environment, if the wrong router is the DR, routes are not exchanged properly.
Duplicate RIDs: If there are two or more routers with the same RID, routes are missing in the topology.
The following sections examine each of these reasons individually and explain how to recognize them in the troubleshooting process.
Interface Not Running the OSPF Process
As discussed earlier, when you use the network ip_address wildcard_mask area area_id command or the ip ospf process_id area area_id interface command, the OSPF process is enabled on interfaces. OSPF then takes the network/subnet the interface is part of and injects it into the LSDB so that it can be advertised to other routers in the autonomous system. Therefore, even interfaces that do not form neighbor relationships with other routers need to be participating in the OSPF process for the interface’s network ID to be advertised.
As discussed earlier in this chapter, the output of show ip protocols displays the network ip_address wildcard_mask area area_id command in addition to the interfaces that were explicitly configured with the ip ospf process_id area area_id interface command. Focus on the highlighted text in Example 8-23. Notice that it states Routing for Networks. Those are not the networks you are routing for. You are routing for the networks associated with the interface on which OSPF will be enabled, based on the network statement. So, 10.1.1.1 0.0.0.0 area 1 means to enable OSPF on the interface with the IP address 10.1.1.1 and place it in Area 1. You can then route for the network associated with that interface. Also, you can see that GigabitEthernet1/0 was explicitly configured to participate in the OSPF process; therefore, OSPF routes for the network associated with that interface as well.
Example 8-23 Verifying OSPF-Enabled Interfaces with show ip protocols
R1# show ip protocols *** IP Routing is NSF aware *** 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 10.1.12.1 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 10.1.1.1 0.0.0.0 area 1 Routing on Interfaces Configured Explicitly (Area 1): GigabitEthernet1/0 Passive Interface(s): Ethernet0/0 GigabitEthernet0/0 Routing Information Sources: Gateway Distance Last Update 10.1.23.2 110 01:00:43 10.1.23.3 110 01:00:43 Distance: (default is 110)
So, what networks are you actually routing for? You’re routing for the networks associated with the interfaces that are now enabled for OSPF. In Example 8-24, you can see the output of the show ip interface command on R1 for Gi0/0 and Gi1/0, which was piped to include only the Internet address. Notice that the addresses are in a /24 network. As a result, the network IDs are 10.1.1.0/24 and 10.1.12.0/24. Those are the networks you are routing for.
Example 8-24 Verifying Network IDs with show ip interface
R1# show ip interface gi0/0 | i Internet Internet address is 10.1.1.1/24 R1# show ip interface gi1/0 | i Internet Internet address is 10.1.12.1/24
Better Source of Information
For an OSPF-learned route to be installed in the routing table, it must be the most believable routing source. Recall that believability is based on administrative distance (AD). OSPF’s AD is 110 for all learned routes: intra, inter, and external. Therefore, if there is another source that is educating the same router about exactly the same network and that source has a better AD, the source with the better AD wins, and its information is installed in the routing table. Example 8-25 shows only the OSPF-installed routes in the router. Notice that there is no OSPF entry for the networks 10.1.1.0/24 and 10.1.12.0/24.
Example 8-25 Sample show ip route ospf Command Output
R1# show ip route ospf Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2 ia - IS-IS inter area, * - candidate default, U - per-user static route o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP + - replicated route, % - next hop override Gateway of last resort is 10.1.12.2 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.1.12.2, 01:15:29, GigabitEthernet1/0 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks O IA 10.1.3.0/24 [110/3] via 10.1.12.2, 01:15:29, GigabitEthernet1/0 O IA 10.1.23.0/24 [110/2] via 10.1.12.2, 01:15:29, GigabitEthernet1/0 O IA 203.0.113.0/24 [110/3] via 10.1.12.2, 01:15:29, GigabitEthernet1/0
In this case, there is a better source for the 10.1.1.0/24 and 10.1.12.0/24 networks. Example 8-26 displays the output of the show ip route 10.1.1.0 255.255.255.0 command. It identifies that this network is directly connected and has an AD of 0. Because a directly connected network has an AD of 0 and an OSPF route has an AD of 110, the directly connected source is installed in the routing table.
Example 8-26 Sample show ip route 10.1.1.0 255.255.255.0 Command Output
R1# show ip route 10.1.1.0 255.255.255.0 Routing entry for 10.1.1.0/24 Known via "connected", distance 0, metric 0 (connected, via interface) Routing Descriptor Blocks: * directly connected, via GigabitEthernet0/0 Route metric is 0, traffic share count is 1
You might be questioning whether 10.1.1.0/24 is in the LSDB because it is directly connected. Remember that when an interface is participating in the routing process, its network is injected into the LSDB as a Type 1 (router) LSA. You can verify this with the show ip ospf database command, as shown in Example 8-27. However, there is no listing for 10.1.1.0/24. This is because you are only looking at a summary of the LSAs in the LSDB. If you want to see the specifics of the LSA, you have to open them up. Example 8-28 shows the output of show ip ospf database router 10.1.12.1. This command opens the Type 1 (router) LSA advertised by the router with the RID 10.1.12.1, which is R1. It shows that 10.1.1.0/24 is in the LSDB and therefore can be advertised in the OSPF process.
Example 8-27 Output of show ip ospf database on R1
R1# show ip ospf database
OSPF Router with ID (10.1.12.1) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
10.1.12.1 10.1.12.1 1025 0x80000009 0x006B41 2
10.1.23.2 10.1.23.2 1210 0x8000002D 0x00E7A3 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.12.2 10.1.23.2 1210 0x80000007 0x00B307
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.3.0 10.1.23.2 1210 0x80000004 0x00D72E
10.1.23.0 10.1.23.2 1210 0x8000001A 0x00C418
203.0.113.0 10.1.23.2 1210 0x80000004 0x004E88
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.23.3 10.1.23.2 1210 0x80000003 0x00C629
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 10.1.23.3 1268 0x80000003 0x00B399 1
Example 8-28 Output of show ip ospf database router 10.1.12.1 on R1
R1# show ip ospf database router 10.1.12.1
OSPF Router with ID (10.1.12.1) (Process ID 1)
Router Link States (Area 1)
LS age: 1368
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 10.1.12.1
Advertising Router: 10.1.12.1
LS Seq Number: 80000009
Checksum: 0x6B41
Length: 48
Number of Links: 2
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.12.2
(Link Data) Router Interface address: 10.1.12.1
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 10.1.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Using a suboptimal source of routing information may not cause users to complain or submit a trouble ticket because they will probably still be able to access the resources they need. However, it might cause suboptimal routing in your network. Figure 8-1 shows a network running two different routing protocols. In this case, which path will be used to send traffic from PC1 to 10.1.1.0/24? If you said the longer EIGRP path, you are correct. Even though it is quicker to use the OSPF path, EIGRP wins by default because it has the lower AD, and suboptimal routing occurs.
Figure 8-1 Which Path Will Be Used from PC1 to 10.1.1.0/24?
Being able to recognize when a certain routing source should be used and when it should not be used is key to optimizing your network and reducing the number of troubleshooting instances related to the network being perceived as being slow. In this case, you might want to consider increasing the AD of EIGRP or lowering the AD of OSPF to optimize routing.
Route Filtering
A distribute list applied to an OSPF process controls which routes are installed into the routing table from the LSDB. Note that this differs from EIGRP, where the distribute list controls routes sent and received between neighbors. The reason this difference exists is that all OSPF routers in an area must have the same LSDB. If you were able to control the routes sent to and received from neighbors, the LSDB would not be the same among the routers in the area, which is not permitted.
To apply a route filter to OSPF, the distribute list is applied in OSPF configuration mode inbound (meaning into the routing table), and the routes installed are controlled by ACLs, prefix lists, or route maps. Therefore, when troubleshooting route filtering for OSPF, you need to consider the following:
Is the distribute list applied in the correct direction?
If the distribute list is using an ACL, is the ACL correct?
If the distribute list is using a prefix list, is the prefix list correct?
If the distribute list is using a route map, is the route map correct?
The show ip protocols command identifies whether a distribute list is applied to the OSPF process, as shown in Example 8-29. This example indicates that there are no outbound filters and that there is an inbound filter that is referencing the prefix list called TEST.
Example 8-29 Verifying Route Filters with show ip protocols
R1# show ip protocols *** IP Routing is NSF aware *** Routing Protocol is "ospf 1" Outgoing update filter list for all interfaces is not set Incoming update filter list for all interfaces is (prefix-list) TEST Router ID 10.1.12.1 Number of areas in this router is 1. 1 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 10.1.1.1 0.0.0.0 area 1 Routing on Interfaces Configured Explicitly (Area 1): GigabitEthernet1/0 Passive Interface(s): Ethernet0/0 GigabitEthernet0/0 Routing Information Sources: Gateway Distance Last Update 10.1.23.2 110 00:00:20 10.1.23.3 110 00:00:20 Distance: (default is 110)
The inbound filter in Example 8-29 is filtered by prefix list TEST. To verify the entries in this prefix list, you issue the show ip prefix-list TEST command, as shown in Example 8-30. If an ACL is applied, you issue the show access-list command. If a route map is applied, you issue the show route-map command.
As shown in Example 8-30, you can verify the command that was used to apply the distribute list in the running configuration.
Example 8-30 Verifying the OSPF Distribute List and Prefix List
R1# show ip prefix-list TEST
ip prefix-list TEST: 2 entries
seq 5 deny 10.1.23.0/24
seq 10 permit 0.0.0.0/0 le 32
R1# show run | section router ospf 1
router ospf 1
area 1 authentication message-digest
passive-interface default
no passive-interface GigabitEthernet1/0
network 10.1.1.1 0.0.0.0 area 1
distribute-list prefix TEST in
Notice in Example 8-31 that the LSDB still has the 10.1.23.0/24 network listed, but it is not installed in the routing table because of the distribute list that is denying 10.1.23.0/24 from being installed.
Example 8-31 Verifying OSPF Routes and LSDB After a Distribute List Is Applied
R1# show ip ospf database
OSPF Router with ID (10.1.12.1) (Process ID 1)
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
10.1.12.1 10.1.12.1 16 0x80000011 0x005B49 2
10.1.23.2 10.1.23.2 13 0x80000033 0x00DBA9 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.12.2 10.1.23.2 12 0x8000000D 0x00A70D
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.3.0 10.1.23.2 16 0x80000002 0x00DB2C
10.1.23.0 10.1.23.2 16 0x80000002 0x00F4FF
203.0.113.0 10.1.23.2 16 0x80000002 0x005286
Summary ASB Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.23.3 10.1.23.2 18 0x80000001 0x00CA27
Type-5 AS External Link States
Link ID ADV Router Age Seq# Checksum Tag
0.0.0.0 10.1.23.3 779 0x80000005 0x00AF9B 1
R1# show ip route
...output omitted...
Gateway of last resort is 10.1.12.2 to network 0.0.0.0
O*E2 0.0.0.0/0 [110/1] via 10.1.12.2, 00:00:02, GigabitEthernet1/0
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C 10.1.1.0/24 is directly connected, GigabitEthernet0/0
L 10.1.1.1/32 is directly connected, GigabitEthernet0/0
O IA 10.1.3.0/24 [110/3] via 10.1.12.2, 00:00:02, GigabitEthernet1/0
C 10.1.12.0/24 is directly connected, GigabitEthernet1/0
L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
O IA 203.0.113.0/24 [110/3] via 10.1.12.2, 00:00:02, GigabitEthernet1/0
Stub Area Configuration
Because all routers in an area need to have the same LSDB, you cannot manipulate the LSAs within an area; however, you can manipulate LSAs that are flowing between areas by using the stub and NSSA OSPF features.
When you create stub areas or NSSAs, you suppress Type 5 LSAs from entering an area at the ABR. With totally stubby areas and totally NSSAs, you suppress Type 5 and Type 3 LSAs from entering an area at the ABR. The routes that would have been learned from the Type 5 and Type 3 LSAs in the area are now replaced by a default route. Because there is a default route, the router has lost visibility of the overall network, and this could produce suboptimal routing if not implemented correctly in highly redundant environments.
As a result, if you are expecting a Type 5 or Type 3 LSA for a specific route, but it is not showing up in the area, you should verify whether the area is a stub area or an NSSA and determine what types of routes are being suppressed. You can verify whether the area connected to the router is a stub area or an NSSA by using the show ip ospf command, as shown in Example 8-32.
Example 8-32 Determining the Type of OSPF Areas
R1# show ip ospf
Routing Process "ospf 1" with ID 10.1.12.1
Start time: 02:23:19.824, Time elapsed: 02:08:52.184
...output omitted...
Reference bandwidth unit is 100 mbps
Area 1
Number of interfaces in this area is 2
It is a stub area
Area has no authentication
SPF algorithm last executed 00:05:46.800 ago
...output omitted...
However, remember that when implementing totally stubby areas or totally NSSAs you are configuring the no-summary keyword only on the ABR. It is not needed on the other routers. Therefore, it is best to review the output of show ip ospf on the ABR, as shown in Example 8-33. In this example, R2 is configured to suppress Type 3 and Type 5 LSAs from entering Area 1. It replaces them with a default route with a cost of 1. So, even though R1 appears to be in a stub area, it is really in a totally stubby area, based on the configuration of R2.
Example 8-33 Determining the Type of OSPF Area on the ABR
R2# show ip ospf
Routing Process "ospf 1" with ID 10.1.23.2
Start time: 02:39:09.376, Time elapsed: 15:19:40.352
...output omitted...
Flood list length 0
Area 1
Number of interfaces in this area is 1
It is a stub area, no summary LSA in this area
Generates stub default route with cost 1
Area has no authentication
...output omitted...
Interface Is Shut Down
As discussed earlier, when the OSPF process is enabled on an interface, the network the interface is part of (that is, the directly connected entry in the routing table) is injected into the OSPF process. If the interface is shut down, there is no directly connected entry for the network in the routing table. Therefore, the network does not exist, and no network can be injected into the OSPF process. The interface must be up/up for routes to be advertised or for neighbor relationships to be formed.
Wrong Designated Router Elected
A multi-access network can have multiple routers residing on a common network segment. Rather than having all routers form a full mesh of adjacencies with one another, a designated router (DR) is elected, and all other routers on the segment form a full adjacency with the DR, as illustrated in Figure 8-2. The rest of the routers form a 2-Way adjacency with each other, and if a BDR exists, they form a full adjacency with the BDR as well.
Figure 8-2 DR Election in an Ethernet Network
A DR is elected based on router priority, with larger priority values being preferable. If routers have equal priorities, the DR is elected based on the highest OSPF RID. A BDR is also elected based on the same criteria. Routers on the multi-access network form full adjacencies with the BDR in case the DR becomes unavailable.
It does not matter which router is elected as the DR in a multi-access Ethernet topology or a full-mesh Frame Relay topology because every router is able to reach the DR since the Layer 2 topology lines up with the Layer 3 addressing. However, over a hub-and-spoke nonbroadcast multi-access (NBMA) network such as Frame Relay or with a Dynamic Multipoint VPN (DMVPN), it does matter who the DR is because the underlying Layer 2 topology does not line up with the Layer 3 addressing.
Figure 8-3 shows a hub-and-spoke Frame Relay or DMVPN network. The multipoint interface (single physical interface or mGRE [Multipoint Generic Routing Encapsulation] tunnel interface) provides connectivity to multiple routers in the same subnet out the single interface, as Ethernet does. However, in this case, the Layer 2 topology is not the same as the Layer 3 topology. The Layer 3 topology indicates that all routers are directly reachable out the interfaces (on the same subnet). The Layer 2 topology says otherwise. You cannot directly reach R2 from R3 and vice versa. You must go through R1.
Figure 8-3 Hub-and-Spoke Topology
Figure 8-4 shows the wrong DR placement. The DR router needs to be reachable through a single hop because of how OSPF neighbor relationships are formed and how routers communicate with the DR. Hellos are established with the multicast address 224.0.0.5, and the DR is reachable at the multicast address 224.0.0.6. Packets destined to these two multicast addresses are not relayed by other routers. Because the DR is responsible for relaying learned routes in a multi-access network, it needs to be centrally located. Therefore, if R2 were the DR, R3 would not be able to form an adjacency with it because R1 does not relay the hello packet. Therefore, R3 cannot communicate with the DR, which means it cannot tell the DR about the 10.1.3.0 network, and as a result, no other router learns about the 10.1.3.0/24 network.
Figure 8-4 Wrong DR Placement
In this case, you need to control who the DR is. It must be R1 to ensure that all routers are able to send LSAs to it and receive LSAs from it, as shown in Figure 8-5.
Figure 8-5 Correct DR Placement
To verify the DR placement, issue the command show ip ospf interface interface_type interface_number on each of the routers. Example 8-34 indicates that R1 considers the router with the RID 3.3.3.3 as the DR at interface 172.16.33.6. R2 considers itself the DR and R1 the BDR. R3 considers itself a DR and R1 a BDR. Therefore, there are two DRs in this hub-and-spoke environment. As a result, routes are not successfully learned by all routers in the topology.
Example 8-34 Verifying the DR
R1# show ip ospf interface ser 1/0 Serial1/0 is up, line protocol is up Internet Address 172.16.33.4/29, Area 0, Attached via Network Statement Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Topology-MTID Cost Disabled Shutdown Topology Name 0 64 no no Base Transmit Delay is 1 sec, State BDR, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 172.16.33.6 Backup Designated router (ID) 1.1.1.1, Interface address 172.16.33.4 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 ...output omitted... R2# show ip ospf interface ser 1/0 Serial1/0 is up, line protocol is up Internet Address 172.16.33.5/29, Area 0, Attached via Network Statement Process ID 1, Router ID 2.2.2.2, Network Type NON_BROADCAST, Cost: 64 Topology-MTID Cost Disabled Shutdown Topology Name 0 64 no no Base Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 2.2.2.2, Interface address 172.16.33.5 Backup Designated router (ID) 1.1.1.1, Interface address 172.16.33.4 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 ...output omitted... R3# show ip ospf interface ser 1/0 Serial1/0 is up, line protocol is up Internet Address 172.16.33.6/29, Area 0, Attached via Network Statement Process ID 1, Router ID 3.3.3.3, Network Type NON_BROADCAST, Cost: 64 Topology-MTID Cost Disabled Shutdown Topology Name 0 64 no no Base Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 172.16.33.6 Backup Designated router (ID) 1.1.1.1, Interface address 172.16.33.4 Timer intervals configured, Hello 30, Dead 120, Wait 120, Retransmit 5 ...output omitted...
To fix this issue, you need to force R1 to be the DR by preventing R2 and R3 from ever wanting to be a DR. On R2 and R3, you go to interface configuration mode and set the OSPF priority to 0, as shown in Example 8-35.
Example 8-35 Changing OSPF Priority on Spokes
R2# config t R2(config)# int ser 1/0 R2(config-if)# ip ospf priority 0 R3# config t R3(config)# int ser 1/0 R3(config-if)# ip ospf priority0
Now the output of show ip ospf interface ser 1/0 on R1, as shown in Example 8-36, indicates that it is the DR and that there are no BDRs because you never want a spoke to back up the DR as it would cause the problem discussed earlier.
Example 8-36 Verifying That the Hub Router Is the DR
R1# show ip ospf interface ser 1/0 Serial1/0 is up, line protocol is up Internet Address 172.16.33.4/29, Area 0, Attached via Network Statement Process ID 1, Router ID 1.1.1.1, Network Type NON_BROADCAST, Cost: 64 Topology-MTID Cost Disabled Shutdown Topology Name 0 64 no no Base Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 1.1.1.1, Interface address 172.16.33.4 No backup designated router on this network Old designated Router (ID) 3.3.3.3, Interface address 172.16.33.6 ...output omitted...
Duplicate Router IDs
The RID uniquely identifies the routers in the OSPF domain. Because the RID is used during the formation of neighbor relationships and to determine which router is advertising a specific LSA, it is imperative that the RIDs are unique in the domain. If there are duplicate RIDs, the network issues can vary. For example, in the same area, the routers are going to see a Type 1 router LSA about networks they do not know about from an RID the same as theirs. Therefore, they think they generated the LSA and a router does not use information contained in an LSA it receives with the same RID as theirs. However, the LSA is not from itself; it just has the same RID, and as a result, you have missing routes on various routers in the domain.
In Figure 8-6, the Type 1 router LSA from R1 is ignored by R3 because the LSA has the same RID as R3, and so R3 thinks it is its own LSA. Therefore, R3 does not learn about 10.1.1.0/24. The same is true for R1; it does not learn about 10.1.3.0/24 because it is ignoring the LSA that R3 sent because it has the same RID.
Figure 8-6 Duplicate RIDs in the Same Area
Having duplicate RIDs in different areas would cause the physical OSPF topology to be different from the way the SPF algorithm sees it. Figure 8-7 shows an OSPF domain with duplicate RIDs in different areas. R1 and R4 both have RID 1.1.1.1. As you can see, R2 sees the router with the RID in both Area 0 and Area 1 (which to R2 is technically the same router, but in this case, physically it is not). This can cause routing issues because some routes may not be passed between areas, causing the LSDB and the routing tables to be incomplete.
Figure 8-7 Duplicate RIDs in Different Areas
If you have exhausted all possible reasons routes might not be appearing in the LSDB or the routing table, look at the RIDs of the routers by using the show ip protocols command, as shown in Example 8-37.
Example 8-37 Verifying OSPF RID
R1# show ip protocols
*** IP Routing is NSF aware ***
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 1.1.1.1
Number of areas in this router is 1. 0 normal 1 stub 0 nssa
Maximum path: 4
...output omitted...
Troubleshooting Miscellaneous OSPFv2 Issues
So far, the focus in this chapter has been on troubleshooting issues related to OSPFv2 neighbor relationships and routes. This section looks at tracking LSAs through the network, route summarization, discontiguous areas, load balancing, and default routes.
Tracking OSPF Advertisements Through a Network
When troubleshooting an OSPF issue and trying to determine why certain entries are in a router’s LSDB, tracking the path of OSPF advertisements can be valuable. For example, notice network 192.168.1.0/24 in the topology provided in Figure 8-8 and consider how this network is entered into the LSDB of the other OSPF routers.
Figure 8-8 Tracking an OSPF Advertisement
The following steps describe how network 192.168.1.0/24, which is directly connected to router R1, is learned by the LSDBs of routers R2, R3, R4, and R5:
Step 1. Router R1 creates a Type 1 router LSA for the 192.168.1.0/24 network in the Area 1 LSDB and floods it into Area 1.
Step 2. Router R2 receives the router LSA for 192.168.1.0/24 and places it in the Area 1 LSDB. R2 runs the shortest path first (SPF) algorithm to determine the best path through Area 1 to reach the 192.168.1.0/24 network. The best result is placed in R2’s routing table (RIB).
Step 3. Router R2 informs Area 0 routers about network 192.168.1.0/24 by injecting a Type 3 LSA about the network into the LSDB of Area 0 and flooding it into Area 0. This LSA includes the cost to reach the 192.168.1.0/24 network, from the perspective of router R2.
Step 4. Each of the other Area 0 routers (that is, routers R3 and R4) receives the Type 3 LSA and adds it to its Area 0 LSDB. These routers run the SPF algorithm to determine the cost to reach router R2. This cost is then added to the cost router R2 advertised in its Type 3 LSA, and the result is stored in the RIBs for routers R3 and R4.
Step 5. Router R4 informs Area 2 routers about network 192.168.1.0/24 by injecting a Type 3 LSA about the network into the LSDB of Area 2 and flooding it into Area 2. This LSA includes the cost to reach the 192.168.1.0/24 network, from the perspective of router R4.
Step 6. Each of the routers in Area 2 receives the Type 3 LSA and adds it to its Area 2 LSDB. These routers run the SPF algorithm to determine the cost to reach router R4. This cost is then added to the cost router R4 advertised in its Type 3 LSA, and the result is stored in the RIB of the routers.
To successfully troubleshoot OSPF-related issues, you should have a solid understanding of this process and the different types of OSPF LSAs. Table 8-4 lists the LSA types you commonly encounter when troubleshooting a Cisco-based OSPF network.
Table 8-4 OSPF LSAs
LSA Type |
Description |
1 |
All OSPF routers source Type 1 LSAs. These advertisements list information about directly connected subnets, the OSPF connection types of a router, and the known OSPF adjacencies of a router. A Type 1 LSA is not sent out its local area. |
2 |
The designated router on a multi-access network sends a Type 2 LSA for that network if the network contains at least two routers. A Type 2 LSA contains a list of routers connected to the multi-access network and, like a Type 1 LSA, is constrained to its local area. |
3 |
A Type 3 LSA is sourced by an ABR. Each Type 3 LSA sent into an area contains information about a network reachable in a different area. Note that network information is exchanged only between the backbone area and a nonbackbone area, as opposed to being exchanged between two nonbackbone areas. |
4 |
Much like a Type 3 LSA, a Type 4 LSA is sourced by an ABR. However, instead of containing information about OSPF networks, a Type 4 LSA contains information stating how to reach an autonomous system boundary router (ASBR). |
5 |
A Type 5 LSA is sourced by an ASBR and contains information about networks reachable outside the OSPF domain. A Type 5 LSA is sent to all OSPF areas except for stub areas. Note that the ABR for a stub area sends default route information into the stub area rather than sending the network-specific Type 5 LSAs. |
7 |
A Type 7 LSA is sourced from an ASBR within an NSSA. Whereas a stub area cannot connect to an external autonomous system, an NSSA can. The Type 7 LSA exists only in the NSSA; therefore, the external routes are announced by the ABR(s) of the NSSA into Area 0 using Type 5 LSAs. In addition, as with a stub area, external routes known to another OSPF area are not forwarded into an NSSA since Type 5 LSAs are not permitted in an NSSA. |
Route Summarization
OSPF is strict about where route summarization can occur. With OSPF, manual route summarization is enabled on an area-by-area basis on an ABR to summarize routes as they enter or leave an area or on an ASBR to summarize external routes being injected into an area. Therefore, when troubleshooting route summarization, you need to keep in mind the following:
Did you enable route summarization on the correct router?
Did you enable route summarization for the correct area?
Did you create the appropriate summary route?
You can find answers to all these questions by using the show ip ospf command, as shown in Example 8-38. In this example, R2 is an area border router, and summary address 10.1.0.0/16 for Area 1 is currently active and being advertised into Area 0.
Example 8-38 Verifying Interarea Route Summarization with show ip ospf
R2# show ip ospf Routing Process "ospf 1" with ID 2.2.2.2 ...output omitted... Event-log enabled, Maximum number of events: 1000, Mode: cyclic It is an area border router Router is not originating router-LSAs with maximum metric ...output omitted... Reference bandwidth unit is 100 mbps Area BACKBONE(0) Number of interfaces in this area is 1 Area has no authentication SPF algorithm last executed 00:03:27.000 ago SPF algorithm executed 14 times Area ranges are Number of LSA 6. Checksum Sum 0x033162 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 Area 1 Number of interfaces in this area is 1 Area has no authentication SPF algorithm last executed 00:03:27.024 ago SPF algorithm executed 13 times Area ranges are 10.1.0.0/16 Active(1) Advertise Number of LSA 9. Checksum Sum 0x0555F1 ...output omitted...
Remember that interarea summaries are created on ABRs with the area range command and that external summaries are created on ASBRs with the summary-address command.
When a summary route is created on a router, so is a summary route to Null0, as shown in the following snippet:
R2# show ip route | include Null O 10.1.0.0/16 is a summary, 00:16:07, Null0
This route to Null0 is created and installed in the routing table to prevent routing loops. It is imperative that this route be in the table to ensure that if a packet is received by this router and is destined to a network that falls within the summary that the router does not really know how to reach (longer match), it is dropped. If the route to Null0 does not exist, and if there is a default route on the router, the router forwards the packet using the default route, and the next-hop router ends up forwarding it back to this router because it is using the summary route, and the local router then forwards it based on the default route, and it comes back. This is a routing loop.
It is important that you create accurate summary routes to ensure that your router is not advertising networks in the summary route that it does not truly know how to reach. If it does, it is possible that it might receive packets to destinations that fall within the summary that it really does not know how to reach. If this is the case, packets are dropped because of the route to Null0.
Unlike EIGRP, which gives the route to Null0 an AD of 5, OSPF gives the route to Null0 an AD of 110, as shown in Example 8-39. This does not ensure that it is more believable than most of the other sources of routing information. Therefore, it is possible that a better routing source could end up forwarding the traffic for networks that are included in the summary route to Null0.
Example 8-39 Verifying the AD of a Local Summary Route to Null 0
R2# show ip route 10.1.0.0 255.255.0.0
Routing entry for 10.1.0.0/16
Known via "ospf 1", distance 110, metric 1, type intra area
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 1, traffic share count is 1
Discontiguous Areas
In a multiarea OSPF network, a backbone area (numbered Area 0) must exist, and all other areas must connect to Area 0. If an area is not physically adjacent to Area 0, routes are not successfully learned by all routers in the OSPF domain. To solve this issue, a virtual link can be configured to logically connect the nonadjacent area with Area 0. Figure 8-9 shows Area 51 not physically connected to Area 0. This results in the 10.1.4.0 network not being learned by any other router in the OSPF domain because an ABR is needed to send Type 3 LSAs into Area 0. R4 is not an ABR in this case because the requirement for an ABR is that one interface must be in Area 0 and one or more interfaces in any other area(s). In this case, R4 has no interfaces in Area 0.
Figure 8-9 Area 51 Not Directly Connected to Area 0
Figure 8-10 shows a similar topology but with Area 0 discontiguous. This results in LSAs not being successfully flooded though the OSPF domain and, as a result, incomplete routing tables.
Figure 8-10 Discontiguous Area 0
You need to be able to recognize these OSPF design issues and understand how to troubleshoot them and implement a solution. The solution is virtual links. A virtual link in both these examples is created through Area 1, which is known as the transit area because it transits LSAs from Area 51 to Area 0 or from Area 0 to Area 0. Note that virtual links are a temporary solution for these issues. A permanent redesign/fix should be performed as soon as possible.
A virtual link is created between the routers connected to the transit area by using their RIDs and the transit area number, as shown in Figure 8-11. The router OSPF configuration mode command on R2 is area 1 virtual-link 4.4.4.4, and the command on R4 is area 1 virtual-link 2.2.2.2. When the virtual link is established, R4 becomes an ABR because it has an interface (virtual interface in this case) in Area 0. Common issues related to failed virtual links include misconfigured area number or RID. If you type in the area number you are trying to connect to Area 0 instead of the transit area number, the virtual link fails to form. If you use the interface IP address rather than the RID, the virtual link fails to form.
Figure 8-11 LSA Flooding with Virtual Links
Example 8-40 shows the output of show ip ospf neighbor on R2. Notice that there is a new neighbor relationship with 4.4.4.4 but that the local interface is OSPF_VL0, which refers to the virtual link interface.
Example 8-40 Verifying a Neighbor Relationship over a Virtual Link
R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 4.4.4.4 0 FULL/ - - 10.1.14.4 OSPF_VL0 3.3.3.3 1 FULL/BDR 00:00:34 10.1.23.3 GigabitEthernet1/0 1.1.1.1 1 FULL/BDR 00:00:35 10.1.12.1 GigabitEthernet0/0
Example 8-41 shows the output of show ip ospf virtual-links, which provides more details about the virtual link. It is not only important to verify that the virtual link is up but that the state is full, which indicates that LSAs have been successfully exchanged.
Example 8-41 Verifying the Virtual Link
R2# show ip ospf virtual-links Virtual Link OSPF_VL0 to router 4.4.4.4 is up Run as demand circuit DoNotAge LSA allowed. Transit area 1, via interface GigabitEthernet0/0 Topology-MTID Cost Disabled Shutdown Topology Name 0 64 no no Base Transmit Delay is 1 sec, State POINT_TO_POINT, Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 Hello due in 00:00:09 Adjacency State FULL (Hello suppressed) Index 2/3, retransmission queue length 0, number of retransmission 0 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0) Last retransmission scan length is 0, maximum is 0 Last retransmission scan time is 0 msec, maximum is 0 msec
Load Balancing
OSPF supports only equal-cost load balancing. Therefore, when troubleshooting load balancing for OSPF, your two primary points of concern are the overall end-to-end cost and the maximum number of paths permitted for load balancing. To verify the maximum number of equal-cost paths an OSPF router is currently configured to support, use the show ip protocols command, as shown in Example 8-42. In this example, R1 is currently using the default value of 4.
If your topology is showing multiple paths to reach certain networks in your organization but they are not all showing up in the routing table, it is than likely because they are not equal-cost paths or the maximum paths value is configured too low.
Example 8-42 Verifying the Maximum Number of Paths for Load Balancing
R1# show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "ospf 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is (prefix-list) TEST
Router ID 1.1.1.1
Number of areas in this router is 2. 2 normal 0 stub 0 nssa
Maximum path: 4
Routing for Networks:
10.1.1.1 0.0.0.0 area 1
Routing on Interfaces Configured Explicitly (Area 1):
GigabitEthernet1/0
...output omitted...
Default Route
With OSPF, a static default route is injected into the routing process using the default-information originate command, not the redistribute static command. Therefore, if you are troubleshooting why a static default route is not being advertised in the OSPF process, use the show run | section router ospf command to verify that the default-information originate command is being used.
OSPFv2 Trouble Tickets
This section presents three trouble tickets related to the topics discussed in this chapter. The purpose of these trouble tickets is to show a process that you can use when troubleshooting in the real world or in an exam environment. All trouble tickets in this section are based on the topology shown in Figure 8-12.
Figure 8-12 OSPFv2 Trouble Tickets Topology
Trouble Ticket 8-1
Problem: Users in the 10.1.1.0/24 network indicate that they are not able to access resources in the 192.168.1.0/24 network.
As always, the first item on the list for troubleshooting is to verify the problem. You access a PC in the 10.1.1.0/24 network and ping an IP address in the 192.168.1.0/24 network; the ping is successful (0% loss), as shown in Example 8-43. However, notice that the reply is from the default gateway at 10.1.1.1, and it states Destination host unreachable. Therefore, the ping is actually technically not successful.
Example 8-43 Destination Unreachable Result from a ping Command on a PC
C:>ping 192.168.1.10 Pinging 192.168.1.10 with 32 bytes of data; Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Reply from 10.1.1.1: Destination host unreachable. Ping statistics for 192.168.1.10: Packets: Sent = 4, Received = 4, lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
The result of this ping tells you two very important things: The PC can reach the default gateway and the default gateway does not know how to get to the 192.168.1.0/24 network. Therefore, you can focus your attention on R1 and work from there.
On R1, you issue the same ping, but it fails, as shown in Example 8-44.
Example 8-44 Failed Ping from R1 to 192.168.1.10
R1# ping 192.168.1.10 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds: ..... Success rate is 0 percent (0/5)
Next, you check R1’s routing table with the show ip route command and notice that there are only connected routes in the routing table, as shown in Example 8-45. R1 is not learning any routes from R2.
Example 8-45 show ip route Output on R1
R1# show ip route ...output omitted... Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks C 10.1.1.0/24 is directly connected, GigabitEthernet0/0 L 10.1.1.1/32 is directly connected, GigabitEthernet0/0 C 10.1.12.0/24 is directly connected, GigabitEthernet1/0 L 10.1.12.1/32 is directly connected, GigabitEthernet1/0
According to Figure 8-12, OSPF is the routing protocol in use. Therefore, you issue the show ip protocols command to verify that OSPF is running on R1. Example 8-46 shows output of the show ip protocols command and confirms that OSPF process 1 is in operation on R1.
Example 8-46 show ip protocols Output on R1
R1# show ip protocols *** IP Routing is NSF aware *** 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 1.1.1.1 Number of areas in this router is 2. 2 normal 0 stub 0 nssa Maximum path: 4 Routing for Networks: 10.1.1.1 0.0.0.0 area 1 Routing on Interfaces Configured Explicitly (Area 1): GigabitEthernet1/0 Passive Interface(s): Ethernet0/0 GigabitEthernet0/0 Routing Information Sources: Gateway Distance Last Update 4.4.4.4 110 01:20:29 2.2.2.2 110 00:48:38 3.3.3.3 110 01:20:29 10.1.23.2 110 16:56:39 203.0.113.3 110 17:10:26 Distance: (default is 110)
Next, you check to see whether R1 has any OSPF neighbors. According to the topology, R2 should be a neighbor. To verify OSPF neighbors, you issue the show ip ospf neighbor command on R1, as shown in Example 8-47. According to the output, R1 is a neighbor with R2.
Example 8-47 show ip ospf neighbor Output on R1
R1# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 1 FULL/DR 00:00:36 10.1.12.2 GigabitEthernet1/0
What is the next best step? Some would consider troubleshooting why the routes are missing on R1 by looking at various features and parameters associated with R1. However, the 192.168.1.0/24 network is in a different area. Who is responsible for telling R1 about 192.168.1.0/24? Is it R4? No. Is it R2? Yes. R2 sends a Type 3 summary LSA into Area 1, which tells Area 1 about the 192.168.1.0/24 network. Therefore, if R2 does not know about 192.168.1.0/24, you can stop troubleshooting on R1. This is a great example of how understanding the flow of different LSAs can save you time while troubleshooting.
On R2, you issue the show ip route command, as shown in Example 8-48, and confirm that R2 does not know about the 192.168.1.0/24 network either. In fact, it has not learned about any networks in Area 0.
Example 8-48 show ip route Output on R2
R2# show ip route ...output omitted... Gateway of last resort is not set 10.0.0.0/8 is variably subnetted, 6 subnets, 3 masks O 10.1.0.0/16 is a summary, 15:15:33, Null0 O 10.1.1.0/24 [110/2] via 10.1.12.1, 01:33:14, GigabitEthernet0/0 C 10.1.12.0/24 is directly connected, GigabitEthernet0/0 L 10.1.12.2/32 is directly connected, GigabitEthernet0/0 C 10.1.23.0/24 is directly connected, GigabitEthernet1/0 L 10.1.23.2/32 is directly connected, GigabitEthernet1/0
Wait! Remember that with OSPF, distribute lists are used to permit or deny routes from being installed in the routing table from the LSDB. Therefore, you might be learning about them and just not installing them.
Example 8-49 shows the output of the LSDB on R2, and as you can see, there are no Area 0 Type 1 router LSAs from R3 (3.3.3.3) or R4 (4.4.4.4). Therefore, you can now officially say that R2 has not been educated about the networks that are missing.
Example 8-49 show ip ospf database Output on R2 Confirming That Routes Are Missing
R2# show ip ospf database
OSPF Router with ID (2.2.2.2) (Process ID 1)
Router Link States (Area 0)
Link ID ADV Router Age Seq# Checksum Link count
2.2.2.2 2.2.2.2 316 0x80000025 0x003B9F 1
Summary Net Link States (Area 0)
Link ID ADV Router Age Seq# Checksum
10.1.0.0 2.2.2.2 1339 0x8000001C 0x00927B
Router Link States (Area 1)
Link ID ADV Router Age Seq# Checksum Link count
1.1.1.1 1.1.1.1 1988 0x80000022 0x007843 2
2.2.2.2 2.2.2.2 316 0x80000024 0x0012BA 1
Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.12.2 2.2.2.2 1589 0x8000001C 0x007C75
Summary Net Link States (Area 1)
Link ID ADV Router Age Seq# Checksum
10.1.23.0 2.2.2.2 61 0x80000020 0x008C66
To receive LSAs, you must have interfaces participating in the OSPF process, and you must have neighbor relationships. The output of show cdp neighbors indicates that R3 is a neighbor, and it is reachable out R2’s local Gig 1/0 interface, as shown in Example 8-50.
Example 8-50 Using show cdp neighbors to Verify Router Interfaces
R2# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
R3 Gig 1/0 178 R 7206VXR Gig 1/0
R1 Gig 0/0 179 R 7206VXR Gig 1/0
The output of the commands show ip ospf interface brief and show ip ospf neighbor, as shown in Example 8-51, shows that R2’s local Gi1/0 interface is participating in the OSPF process but does not have a neighbor on the interface.
Example 8-51 Verifying OSPF-Enabled Interfaces and Neighbors
R2# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Gi1/0 1 0 10.1.23.2/24 1 DR 0/0 Gi0/0 1 1 10.1.12.2/24 1 DR 1/1 R2# show ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 1 FULL/BDR 00:00:37 10.1.12.1 GigabitEthernet0/0
So, you can now hypothesize that the issue is related to R2 and R3 not having a neighbor adjacency. What would cause this? As the earlier discussion in this chapter indicates, many different issues could cause this. Recall that the majority of them are interface related, and using the spot-the-difference troubleshooting method would come in handy. You can do that by examining the output of show ip ospf interface gigabitEthernet 1/0 on R2 and R3, as shown in Example 8-52.
Example 8-52 Comparing the OSPF Interface Parameters of R2 and R3
R2# show ip ospf interface gigabitEthernet 1/0 GigabitEthernet1/0 is up, line protocol is up Internet Address 10.1.23.2/24, Area 0, Attached via Network Statement Process ID 1, Router ID 2.2.2.2, Network Type BROADCAST, Cost: 1 Topology-MTID Cost Disabled Shutdown Topology Name 0 1 no no Base Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 2.2.2.2, Interface address 10.1.23.2 No backup designated router on this network Timer intervals configured, Hello 11, Dead 44, Wait 44, Retransmit 5 oob-resync timeout 44 Hello due in 00:00:08 Supports Link-local Signaling (LLS) Cisco NSF helper support enabled IETF NSF helper support enabled Index 1/2, flood queue length 0 Next 0x0(0)/0x0(0) Last flood scan length is 0, maximum is 3 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Message digest authentication enabled Youngest key id is 1 R3# show ip ospf interface gigabitEthernet 1/0 GigabitEthernet1/0 is up, line protocol is up Internet Address 10.1.23.3/24, Area 0, Attached via Network Statement Process ID 1, Router ID 3.3.3.3, Network Type BROADCAST, Cost: 1 Topology-MTID Cost Disabled Shutdown Topology Name 0 1 no no Base Transmit Delay is 1 sec, State DR, Priority 1 Designated Router (ID) 3.3.3.3, Interface address 10.1.23.3 No backup designated router on this network Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5 oob-resync timeout 40 Hello due in 00:00:04 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 1, maximum is 2 Last flood scan time is 0 msec, maximum is 4 msec Neighbor Count is 0, Adjacent neighbor count is 0 Suppress hello for 0 neighbor(s) Message digest authentication enabled Youngest key id is 1
Now answer the following questions:
Are the interfaces up? Yes
Are the interfaces in the same subnet? Yes
Are the interfaces in the same area? Yes
Do the routers have unique RIDs? Yes
Are the interfaces using compatible network types? Yes
Do hello and dead timers match? No (This is a possible reason.)
Do authentication parameters match? Enabled and key match, but not sure about key string without checking the running configuration (This is a possible reason.)
As you can see in Example 8-52, the hello and dead timers do not match, but they must. The output of show run interface gigabitEthernet 1/0 on R2, as shown in Example 8-53, indicates that the command ip ospf hello-interval 11 is configured.
Example 8-53 Verifying Interface Configuration on R2
R2# show run interface gigabitEthernet 1/0
Building configuration...
Current configuration : 196 bytes
!
interface GigabitEthernet1/0
ip address 10.1.23.2 255.255.255.0
ip ospf authentication message-digest
ip ospf message-digest-key 1 md5 CISCO
ip ospf hello-interval 11
negotiation auto
end
When you run the no ip ospf hello-interval 11 command, you receive the following syslog message on R2:
%OSPF-5-ADJCHG: Process 1, Nbr 3.3.3.3 on GigabitEthernet1/0 from LOADING to FULL, Loading Done
This confirms that the adjacency was formed. You can also review the output of the routing table on R2 by using the show ip route command to confirm that the routes are learned, as shown in Example 8-54.
Example 8-54 Verifying Routes in the Routing Table on R2
R2# show ip route ...output omitted... Gateway of last resort is 10.1.23.3 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.1.23.3, 00:01:00, GigabitEthernet1/0 10.0.0.0/8 is variably subnetted, 8 subnets, 3 masks O 10.1.0.0/16 is a summary, 00:01:49, Null0 O 10.1.1.0/24 [110/2] via 10.1.12.1, 00:01:00, GigabitEthernet0/0 O 10.1.3.0/24 [110/2] via 10.1.23.3, 00:01:00, GigabitEthernet1/0 C 10.1.12.0/24 is directly connected, GigabitEthernet0/0 L 10.1.12.2/32 is directly connected, GigabitEthernet0/0 C 10.1.23.0/24 is directly connected, GigabitEthernet1/0 L 10.1.23.2/32 is directly connected, GigabitEthernet1/0 O 10.1.34.0/24 [110/2] via 10.1.23.3, 00:01:00, GigabitEthernet1/0 O 192.168.1.0/24 [110/3] via 10.1.23.3, 00:01:00, GigabitEthernet1/0 O 203.0.113.0/24 [110/2] via 10.1.23.3, 00:01:00, GigabitEthernet1/0
R1 also knows about the routes now, as shown in Example 8-55, which displays the output of show ip route on R1.
Example 8-55 Verifying Routes in the Routing Table on R1
R1# show ip route ...output omitted... Gateway of last resort is 10.1.12.2 to network 0.0.0.0 O*E2 0.0.0.0/0 [110/1] via 10.1.12.2, 00:00:13, GigabitEthernet1/0 10.0.0.0/8 is variably subnetted, 7 subnets, 2 masks C 10.1.1.0/24 is directly connected, GigabitEthernet0/0 L 10.1.1.1/32 is directly connected, GigabitEthernet0/0 O IA 10.1.3.0/24 [110/3] via 10.1.12.2, 00:00:19, GigabitEthernet1/0 C 10.1.12.0/24 is directly connected, GigabitEthernet1/0 L 10.1.12.1/32 is directly connected, GigabitEthernet1/0 O IA 10.1.23.0/24 [110/2] via 10.1.12.2, 00:00:19, GigabitEthernet1/0 O IA 10.1.34.0/24 [110/3] via 10.1.12.2, 00:00:19, GigabitEthernet1/0 O IA 192.168.1.0/24 [110/4] via 10.1.12.2, 00:00:19, GigabitEthernet1/0 O IA 203.0.113.0/24 [110/3] via 10.1.12.2, 00:00:19, GigabitEthernet1/0
Finally, you ping from the PC again, and the ping is successful, as shown in Example 8-56.
Example 8-56 A Successful Ping from the 10.1.1.0/24 Network to the 192.168.1.0/24 Network
C:>ping 192.168.1.10 Pinging 192.168.1.10 with 32 bytes of data: Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Ping statistics for 192.168.1.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Trouble Ticket 8-2
Problem: Users in the 10.1.1.0/24 network indicate that they are not able to access resources in the 192.168.1.0/24 network.
As always, the first item on the list for troubleshooting is to verify the problem. You access a PC in the 10.1.1.0/24 network and ping an IP address in the 192.168.1.0/24 network, and it is successful (0% loss), as shown in Example 8-57. However, notice that the reply is from 10.1.23.2, and it states TTL expired in transit. Therefore, it was technically not successful.
Example 8-57 TTL Expired in Transit Result from the ping Command on PC
C:>ping 192.168.1.10 Pinging 192.168.1.10 with 32 bytes of data: Reply from 10.1.23.2: TTL expired in transit. Reply from 10.1.23.2: TTL expired in transit. Reply from 10.1.23.2: TTL expired in transit. Reply from 10.1.23.2: TTL expired in transit. Ping statistics for 192.168.1.10: Packets: sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
The result of this ping tells you two very important things: The PC can reach the default gateway at 10.1.1.1, and the device at 10.1.23.2 expired the packet because the TTL reached 0, and the device sent an ICMP time exceeded message back to the PC.
Pause for a moment and think about this. If the TTL expired in transit, it means that the packet did not reach the destination before the TTL decremented to 0. Each time a router touches the packet, it decrements the TTL by 1. Normally the TTL is set to 255 by default. Unless it was modified (which you did not do), the packet bounced around the network and went through approximately 255 routers before the device at IP 10.1.23.2 decremented the TTL to 0 and sent the ICMP TTL expired message. Because Figure 8-12 clearly shows that there are only four routers from 10.1.1.0/24 to 192.168.1.0/24, the packet is bouncing around the network somewhere. Running a traceroute from the PC will help you identify this, as shown in Example 8-58. This example shows that R3 (10.1.23.3) and R2 (10.1.23.2) are bouncing the packet back and forth.
Example 8-58 Traceroute Showing that R2 and R3 Are Bouncing the Packet Back and Forth
C:>tracert 192.168.1.10 Tracing route to 192.168.1.10 over a maximum of 30 hops 1 23 ms 15 ms 10 ms 10.1.1.1 2 36 ms 30 ms 29 ms 10.1.12.2 3 53 ms 50 ms 39 ms 10.1.23.3 4 61 ms 39 ms 40 ms 10.1.23.2 5 61 ms 69 ms 59 ms 10.1.23.3 6 68 ms 50 ms 69 ms 10.1.23.2 7 * ms 78 ms 89 ms 10.1.23.3 8 87 ms 69 ms * ms 10.1.23.2 ...output omitted... 29 175 ms 169 ms 179 ms 10.1.23.3 30 204 ms 189 ms 189 ms 10.1.23.2 Trace complete.
You can deduce from this that R3 is not routing the packet correctly. It is sending the packet to R2 instead of R4. Accessing R3 and issuing the show ip ospf database router 4.4.4.4 command, as shown in Example 8-59, clearly indicates that R3 is learning about network 192.168.1.0/24 from R4. However, instead of using R4 as a next hop, it is using R2 because it is sending the packets to R2, as shown in the earlier trace.
Example 8-59 Verifying Whether a Route Is in an OSPF Database
R3# show ip ospf database router 4.4.4.4
OSPF Router with ID (3.3.3.3) (Process ID 1)
Router Link States (Area 0)
LS age: 894
Options: (No TOS-capability, DC)
LS Type: Router Links
Link State ID: 4.4.4.4
Advertising Router: 4.4.4.4
LS Seq Number: 80000004
Checksum: 0xEA47
Length: 48
Number of Links: 2
Link connected to: a Transit Network
(Link ID) Designated Router address: 10.1.34.4
(Link Data) Router Interface address: 10.1.34.4
Number of MTID metrics: 0
TOS 0 Metrics: 1
Link connected to: a Stub Network
(Link ID) Network/subnet number: 192.168.1.0
(Link Data) Network Mask: 255.255.255.0
Number of MTID metrics: 0
TOS 0 Metrics: 1
Now you can look at the routing table to see whether you are installing this network in the routing table. The output of the command show ip route ospf on R3, as shown in Example 8-60, indicates that this OSPF-learned route is not being installed in the routing table.
Example 8-60 Output of show ip route ospf on R3
R3# show ip route ospf ...output omitted... Gateway of last resort is 203.0.113.1 to network 0.0.0.0 10.0.0.0/8 is variably subnetted, 7 subnets, 3 masks O IA 10.1.0.0/16 [110/2] via 10.1.23.2, 01:25:02, GigabitEthernet1/0
It’s time to hypothesize! What would cause R3 to learn about the route but not install it in the routing table? Two possibilities are route filtering and a better source. If you harness your knowledge and really focus on what is happening, you can figure it out. R3 is routing packets destined to 192.168.1.0/24, which means there must be some entry in the routing table, or policy-based routing must be enforced.
The output of the command show ip route 192.168.1.0 255.255.255.0 on R3 confirms that there is an entry in the routing table on R3, as shown in Example 8-61. However, it is a static entry with an AD of 1 pointing to 10.1.23.2. It looks like you found the problem. There is a better source of routing information, according to AD.
Example 8-61 Output of show ip route 192.168.1.0 255.255.255.0 on R3
R3# show ip route 192.168.1.0 255.255.255.0 Routing entry for 192.168.1.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.1.23.2 Route metric is 0, traffic share count is 1
The command show run | include ip route, as shown in Example 8-62, confirms that a static route exists.
Example 8-62 Output of show run | include ip route
R3# show run | include ip route ip route 0.0.0.0 0.0.0.0 203.0.113.1 ip route 192.168.1.0 255.255.255.0 10.1.23.2
After you remove this command from R3 with the no ip route 192.168.1.0 255.255.255.0 10.1.23.2 command, pinging from the PC is successful, as shown in Example 8-63.
Example 8-63 A Successful Ping to the 192.168.1.0/24 Network
C:>ping 192.168.1.10 Pinging 192.168.1.10 with 32 bytes of data: Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Reply from 192.168.1.10: bytes=32 time 1ms TTL=128 Ping statistics for 192.168.1.10: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
Trouble Ticket 8-3
Problem: Routers R1 and R2 are not forming a neighbor adjacency.
The first item on the list for troubleshooting is to verify the problem. You access R1 and issue the show ip ospf neighbor command, as shown in Example 8-64, and it confirms that there is no neighbor relationship with R2.
Example 8-64 Verifying R1’s OSPF Neighbors
R1# show ip ospf neighbor R1#
You know that to have a neighbor relationship, you need interfaces participating in the OSPF process. The command show cdp neighbors confirms that R2 is connected to R1’s local Gig 1/0 interface, as shown in Example 8-65. Therefore, you need to enable OSPF on that interface.
Example 8-65 Verifying R1’s CDP Neighbors
R1# show cdp neighbors
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone,
D - Remote, C - CVTA, M - Two-port Mac Relay
Device ID Local Intrfce Holdtme Capability Platform Port ID
R2 Gig 1/0 142 R 7206VXR Gig 0/0
The output of show ip ospf interface brief confirms that Gi1/0 is participating in the OSPF process, as shown in Example 8-66. However, based on Figure 8-12, it is not in the correct area. It should be in Area 1.
Example 8-66 Verifying R1’s OSPF-Enabled Interfaces
R1# show ip ospf interface brief Interface PID Area IP Address/Mask Cost State Nbrs F/C Gi0/0 1 1 10.1.1.1/24 1 DR 0/0 Gi1/0 1 51 10.1.12.1/24 1 DR 0/0
Based on Example 8-66, Gi1/0 has IP address 10.1.12.1/24. Therefore, you need a network command that includes that IP address and places the interface in Area 1. The output of show run | section router ospf indicates that there is a network command that will enable the routing process on Gi1/0 and put it in Area 1, as shown in Example 8-67.
Example 8-67 Verifying R1’s OSPF Configuration
R1# show run | section router ospf router ospf 1 router-id 1.1.1.1 area 1 authentication message-digest passive-interface default no passive-interface GigabitEthernet1/0 network 10.1.1.1 0.0.0.0 area 1 network 10.1.12.1 0.0.0.0 area 1
If you are scratching your head, you’re not the only one at this point. The running configuration clearly shows a command that puts Gi1/0 in Area 1, yet the output of show ip ospf interface brief clearly shows that it is in Area 51. If you have not figured out why this happened, keep reading.
Recall that there are two ways to enable OSPF on an interface: with the network area command in router OSPF configuration mode and with the ip ospf area interface configuration mode command.
The ip ospf area command overrides the network area command if both commands are configured. Example 8-68 shows the GigabitEthernet1/0 interface configuration on R1, using the show run interface gigabitEthernet 1/0 command.
Example 8-68 Verifying R1’s GigabitEthernet1/0 Configuration
R1# show run interface gigabitEthernet 1/0 Building configuration... Current configuration : 183 bytes ! interface GigabitEthernet1/0 ip address 10.1.12.1 255.255.255.0 ip ospf authentication-key CISCO ip ospf message-digest-key 1 md5 CISCO ip ospf 1 area 51 negotiation auto end
Here is the issue. The ip ospf 1 area 51 command overrides the network 10.1.12.1 0.0.0.0 area 1 command. You either need to change the ip ospf 1 area 51 command so that it states area 1 or remove it completely so that the network command can be used.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple choices for exam preparation: the exercises here, Chapter 24, “Final Preparation,” and the exam simulation questions in the Pearson Test Prep software. The questions that follow present a bigger challenge than the exam itself because they use an open-ended question format. By using this more difficult format, you can exercise your memory better and prove your conceptual and factual knowledge of this chapter. You can find the answers to these questions in the appendix.
Review All Key Topics
Table 8-5 Key Topics
Key Topic Element |
Description |
Page Number |
Verifying OSPF neighbors with show ip ospf neighbor |
||
List |
Reasons an OSPF neighbor relationship might not form |
|
Adjacency states |
||
Verifying OSPF interfaces with show ip ospf interface brief |
||
Displaying OSPF interface timers on R1 Gigabit Ethernet 1/0 |
||
Section |
Mismatched area numbers |
|
Determining the type of OSPF areas |
||
Paragraph |
The passive interface feature and troubleshooting passive interface issues |
|
Verifying OSPF area authentication |
||
Verifying OSPF authentication key |
||
Section |
MTU mismatch |
|
OSPF network types and characteristics |
||
List |
Reasons an OSPF route might be missing from either the LSDB or the routing table |
|
List |
Considerations when troubleshooting route filtering |
|
Section |
Stub area configuration |
|
Paragraph |
The importance of the DR election in a hub-and-spoke multi-access network |
|
OSPFv2 LSAs |
||
List |
Considerations when troubleshooting route summarization issues |
|
Verifying the virtual link |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
OSPF link-state database (LSDB)
link-state advertisement (LSA)
Dijkstra’s shortest path first (SPF) algorithm
Use the Command Reference to Check Your Memory
This section includes the most important configuration and verification commands covered in this chapter. It might not be necessary to memorize the complete syntax of every command, but you should be able to remember the basic keywords that are needed.
To test your memory of the commands, cover the right side of Table 8-6 with a piece of paper, read the description on the left side, and then see how much of the command you can remember.
Table 8-6 Command Reference
Task |
Command Syntax |
Display the IPv4 routing protocols enabled on the device; for OSPFv2, display whether any route filters are applied, the RID, the number of areas the router is participating in, the types of areas, the maximum paths for load balancing, the network area command, the interfaces explicitly participating in the routing process, passive interfaces, routing information sources, and the AD |
show ip protocols |
Display general OSPF parameters, including the PID, the RID, the reference bandwidth, the areas configured on the router, the types of areas (stub, totally stubby, NSSA, and totally NSSA), and area authentication |
show ip ospf |
Display the interfaces that are participating in the OSPF process |
show ip ospf interface brief |
Display detailed information about the interfaces participating in the OSPF process, including interface IPv4 address and mask, area ID, PID, RID, network type, cost, DR/BDR, priority, and timers |
show ip ospf interface |
Display the OSPF devices that have formed a neighbor adjacency with the local router |
show ip ospf neighbor |
Display the OSPF routes that have been installed in the IPv4 routing table |
show ip route ospf |
Display the OSPF link-state database |
show ip ospf database |
Provide information about the status of OSPF virtual links that are required for areas not physically adjacent to the backbone area (that is, Area 0) |
show ip ospf virtual-links |
Display real-time information related to the exchange of OSPF hello packets; useful for identifying mismatched OSPF timers and mismatched OSPF area types |
debug ip ospf hello |
Display the transmission and reception of OSPF packets in real time |
debug ip ospf packet |
Display real-time updates about the formation of an OSPF adjacency; useful for identifying mismatched area IDs and authentication information |
debug ip ospf adj |
Display real-time information about OSPF events, including the transmission and reception of hello messages and LSAs; might be useful on a router that appears to be ignoring hello messages received from a neighboring router |
debug ip ospf events |
The ENARSI 300-410 exam focuses on practical, hands-on skills that are used by a networking professional. Therefore, you should be able to identify the commands needed to configure, verify, and troubleshoot the topics covered in this chapter.