OSPF

The OSPF routing protocol was drafted by the IGP Working Group of the Internet Engineering Task Force (IETF). It was developed because RIP was not able to scale for large, heterogeneous networks. The OSPF specification is defined in RFC 2338, "OSPF Version 2." It is based on the Shortest Path First (SPF) algorithm (usually referred to as the Dijkstra algorithm, per its author's name).

OSPF is a link-state routing protocol. It sends information about attached interfaces, metrics used, and other variables to its peers or neighbors. This information is called link-state advertisements (LSAs). They are sent to all the peers within a specific hierarchical area.

OSPF operates in hierarchies of separate autonomous systems. These autonomous systems can be divided into groups of contiguous networks called areas. Routers that are part of more than one area are referred to as Area Border Routers (ABRs). Figure 6-6 illustrates an example of this concept.

Figure 6-6. Areas in OSPF

As shown in Figure 6-6, more than one OSPF area can be joined together by an ABR. On the other hand, an OSPF backbone, OSPF area 0, must be present to propagate routing information to all other areas. The Cisco ASA can be configured to act as an ABR. It will provide not only connectivity, but also security while performing type 3 LSA filtering. Type 3 LSAs refer to summary links and are sent by ABRs to advertise destinations outside the area. The OSPF ABR type 3 LSA filtering feature gives the user improved control of route distribution between OSPF areas. This feature also provides the capability of hiding the private networks by using Network Address Translation (NAT) without advertising them.

Figure 6-7 provides an example of how the Cisco ASA can be configured as an ABR and provide LSA type 3 filtering.

Figure 6-7. Cisco ASA OSPF LSA Type 3 Filtering

Note

If the Cisco ASA is configured as an Autonomous System Boundary Router (ASBR) in a private network, it will propagate Type 5 LSAs to the entire autonomous system, including public areas. Type 5 LSAs define external routes to the autonomous system. This is not a recommended security practice because this will cause all private networks to be externally advertised.

Note

The ospf database-filter all out command can be used to filter out all outgoing LSAs to an OSPF interface during synchronization and flooding.

The following section provides different sample configurations explaining all the OSPF features supported by Cisco ASA.

Configuring OSPF

Cisco ASA supports several OSPF features and capabilities. The following summarizes the Cisco ASA OSPF support:

• Intra-area, interarea, and external (Type 1 and Type 2) routes
• Support to act as a designated router (DR)
• Support to act as a backup designated router (BDR)
• Support to act as an ABR
• Support to act as an ASBR, with route redistribution between OSPF processes including OSPF, static, and connected routes
• Virtual links
• OSPF authentication (both clear-text and MD5 authentication)
• Stub areas and not-so-stubby areas (NSSAs)
• ABR type 3 LSA filtering
• OSPF neighbor command and dynamic routing over VPN
• Load balancing between a maximum of three peers on a single interface, using equal-cost multipath (ECMP) routes

The following sections provide configuration examples for most of these features.

Enabling OSPF

The topology illustrated in Figure 6-8 is used in this example. It includes a Cisco ASA connected to a router named R1 on its inside interface. This router is also connected to two other routers (R2 and R3).

Figure 6-8. Basic OSPF Configuration

In this first example, the Cisco ASA, R1, R2, and R3 are all configured in area 0.

To initially configure OSPF, perform these tasks:

Step 1.

Create an OSPF routing process. To enable OSPF on the Cisco ASA, creating an OSPF routing process:   Chicago# configure terminal Chicago(config)# router ospf 1 The number 1 is used as an identification parameter for the OSPF routing process. This number does not have to match the peer's OSPF process because it has only local significance. It can be configured with a value from 1 to 65,535. A unique value must be allocated for each OSPF routing process within the Cisco ASA.

Step 2.

Define the interface(s) on which OSPF will run. The network command specifies the interfaces that will run OSPF. Further-more, it specifies the area to be associated with that interface. You can use the network address or the address of the interface where you want to enable OSPF. Use the network command while enabling OSPF on the inside interface of the Cisco ASA:   Chicago# configure terminal Chicago(config)# router ospf 1 Chicago(config-router)# network 192.168.10.0 255.255.255.0 area 0 Chicago(config-router)# exit Chicago(config)# exit In this example, the network command is added to the configuration. It is followed by the network address and a 24-bit mask. It also shows that this interface has been added to area 0. The OSPF peer must also be configured for area 0.   Note Unlike the Cisco I OS routers, the Cisco ASA network command does not use an inverse mask. The routing table is as follows:   Chicago# show route C 192.168.10.0 255.255.255.0 is directly connected, inside C 209.165.200.224 255.255.255.224 is directly connected, outside O 192.168.20.0 255.255.255.0 [110/11] via 192.168.10.2, 0:00:55, inside O 192.168.13.0 255.255.255.0 [110/11] via 192.168.10.2, 0:00:55, inside

Note

The output of show route has two routes learned via OSPF on the inside interface of Cisco ASA. The first number in the brackets is the administrative distance of the information source. The second number is the metric for the route.

 

Virtual Links

All areas must talk to area 0 (the backbone area). There is the probability that this will not always be possible. However, in OSPF, a mechanism provides a solution for this problem. Virtual links can be configured to connect an area through a nonbackbone area. They can also be used to connect two parts of a segmented backbone through nonbackbone areas. To configure a virtual link on the Cisco ASA, use the following command syntax:

 area area_id virtual-link router_id [authentication [message-digest | null]]

 [hello-interval seconds] [retransmit-interval seconds] [transmit-delay seconds]

 [dead-interval seconds] [authentication-key password] [message-digest-key

 id md5 password]

Figure 6-9 illustrates a network topology where a Cisco ASA is configured with a virtual link to a router located on a DMZ interface.

Figure 6-9. Virtual Link Example

At first, the virtual link is down because the Cisco ASA does not know how to reach the router labeled DMZ-R2. All the LSAs in area 1 need to be flooded, and the shortest path first (SPF) algorithm must run within area 1 in order for the Cisco ASA to successfully reach DMZ-R2 through area 1. In this example, area 1 is the transit area. After the Cisco ASA can reach DMZ-R2, they try to form an adjacency across the virtual link. Once the Cisco ASA and the DMZ-R2 router become adjacent on the virtual link, DMZ-R2 becomes an ABR because it now has a link in area 0. Consequently, a summary LSA for the networks in area 0 and area 1 is created. Example 6-11 shows the Cisco ASA OSPF virtual link configuration.

Example 6-11. Virtual Link Configuration Example

interface GigabitEthernet0/0

nameif outside

 security-level 0

 ip address 209.165.200.225 255.255.255.248

!

interface GigabitEthernet0/1

nameif inside

 security-level 100

 ip address 192.168.10.1 255.255.255.0

!

interface GigabitEthernet0/2

nameif DMZ

 security-level 50

 ip address 192.168.4.1 255.255.255.0

!

router ospf 1

 network 192.168.4.1 255.255.255.255 area 1

 network 192.168.10.0 255.255.255.0 area 0

 area 1 virtual-link 192.168.3.1

 log-adj-changes

In Example 6-11, the Cisco ASA is configured with a DMZ interface with the IP address of 192.168.4.1. DMZ-R2's IP address is 192.168.3.1. The output of the show ospf virtual-links is included in Example 6-12.

Example 6-12. Output of show ospf virtual-links After Virtual Link Was Created

Chicago# show ospf virtual-links

Virtual Link DMZ to router 192.168.3.1 is up

 Run as demand circuit

 DoNotAge LSA allowed.

 Transit area 1, via interface DMZ, Cost of using 10

 Transmit Delay is 1 sec, State UP,

 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit

 

Configuring OSPF Authentication

Cisco ASA supports both plain-text and MD5 OSPF authentication. MD5 authentication is recommended, because it is more secure than plain-text authentication. When configuring authentication, an entire area must be configured with the same type of authentication. For example, if area 1 is configured for authentication, all devices running OSPF must run the same type of authentication. Figure 6-10 includes an example of a Cisco ASA performing MD5 authentication on its inside interface. All routers and the Cisco ASA reside in area 0, and they must use the same authentication type and shared secret (password) to learn routes from each other.

Figure 6-10. OSPF MD5 Authentication Example

Example 6-13 includes the Cisco ASA configuration. The shared secret in use is cisco123. The Cisco ASA will only accept routes from the router labeled R1 if authentication is successful.

Example 6-13. OSPF MD5 Authentication Configuration Example

interface GigabitEthernet0/0

nameif outside

 security-level 0

 ip address 209.165.200.225 255.255.255.248

!

interface GigabitEthernet0/1

nameif inside

 security-level 100

 ip address 192.168.10.1 255.255.255.0

 ospf message-digest-key 1 md5 cisco123

 ospf authentication message-digest

!

interface GigabitEthernet0/2

nameif DMZ

 security-level 50

 ip address 192.168.4.1 255.255.255.0

 ospf message-digest-key 1 md5 cisco123

 ospf authentication message-digest

!

router ospf 1

 network 192.168.4.1 255.255.255.255 area 1

 network 192.168.10.0 255.255.255.0 area 0

 area 0 authentication message-digest

 area 1 authentication message-digest

 log-adj-changes

!

The Cisco ASA also provides plain-text authentication that can be configured under the Ethernet interfaces. Although plain-text authentication is less secure than MD5 authentication, it is sometimes used when communicating with Layer 3 devices that do not support MD5 authentication. Example 6-14 shows how to configure plain-text authentication.

Example 6-14. OSPF Plain-Text Authentication Configuration Example

interface GigabitEthernet0/0

nameif outside

 security-level 0

 ip address 209.165.200.225 255.255.255.248

!

interface GigabitEthernet0/1

nameif inside

 security-level 100

 ip address 192.168.10.1 255.255.255.0

 ospf authentication-key cisco123

 ospf authentication

!

interface GigabitEthernet0/2

nameif DMZ

 security-level 50

 ip address 192.168.4.1 255.255.255.0

 ospf authentication-key cisco123

 ospf authentication

!

router ospf 1

 network 192.168.4.0 255.255.255.0 area 1

 network 192.168.10.0 255.255.255.0 area 0

 area 0 authentication

 area 1 authentication

 log-adj-changes

OSPF virtual links can also be authenticated using MD5 or plain-text authentication. Example 6-15 demonstrates how to enable MD5 authentication in the virtual link configuration previously discussed. The MD5 key ID value is 1 and the shared secret or password is cisco123.

Example 6-15. Virtual Link MD5 Authentication Configuration Example

router ospf 1

 network 192.168.4.1 255.255.255.255 area 1

 network 192.168.10.0 255.255.255.0 area 0

 area 1 virtual-link 192.168.3.1 authentication message-digest

 area 1 virtual-link 192.168.3.1 message-digest-key 1 md5 cisco123

 router-id 192.168.4.1

 log-adj-changes

Note

The authentication type in both areas should match.

 

Configuring the Cisco ASA as an ASBR

The Cisco ASA can be configured to act as an ASBR. It can perform route redistribution between different OSPF processes, static routes, or directly connected subnets. To configure redistribution, use the redistribute subcommand under the respective OSPF process by using the following command syntax:

 redistribute static|connected [metric metric-value] [metric-type metric-type]

 [route-map name] [tag tag-value] [subnets]

 redistribute ospf pid [metric metric-value] [metric-type metric-type] [route-map

 name] [tag tag-value ] [subnets] [match {internal | external [1|2] | nssa-external

 [1|2]}]

Table 6-2 lists all the options of the redistribute subcommand.

Table 6-2. redistribute Subcommand Options

Option	Description
connected	Redistributes directly connected subnets into OSPF
ospf	Redistributes routes from a different OSPF process
static	Redistributes static routes
subnets	specifies that subnet information should be redistributed into OSPF
pid	Process ID of the OSPF process from which routes will be redistributed
metric-value	Metric used for the redistributed route
name	Identifier of a configured route map
metric-type	Used to select type 1 or type 2 external routes
tag-value	32-bit decimal value attached to each external route
external	Used to redistribute OSPF external routes
internal	Used to redistribute OSPF internal routes
nssa-external	Used to redistribute OSPF NSSA external routes

Example 6-16 shows how to redistribute all the static routes into OSPF.

Example 6-16. Static Route Redistribution Example

Chicago(config)# route inside 192.168.4.0 255.255.255.0 192.168.10.2 1

Chicago(config)# router ospf 1

Chicago(config-router)# network 192.168.10.0 255.255.255.0 area 0

Chicago(config-router)# redistribute static metric 10 subnets

A static routes is configured in Example 6-16. These are then redistributed into OSPF as shown in the highlighted line. The static routes are redistributed with a metric value of 10.

Tip

Use the subnets attribute to allow the Cisco ASA to consider any configured subnets. This is commonly used when redistributing other routing protocols into OSPF. Only classful routes are redistributed if you do not specify the subnets attribute.

 

Stub Areas and NSSAs

An ASBR advertises external routes throughout the OSPF autonomous system. However, in some situations, there is no need to advertise external routes into an area to reduce the size of the OSPF database. A stub area is an area that does not allow the advertisements of external routes. In stub areas, a default summary route is injected along with information about networks that belong to other areas within the same OSPF network. Use the stub option with the area OSPF subcommand to configure this feature in the Cisco ASA. The following is the command syntax:

 area area-id stub [no-summary]

Tip

Use the no-summary attribute if you do not want to send summary LSAs into the stub area.

If an area is configured as a stub, all the routers within the area must also be configured as stub routers. Otherwise, the neighbor relationship will not be established.

The OSPF NSSA feature is defined in RFC 3101, "The OSPF Not-So-Stubby Area (NSSA) Option." Redistribution of routes into an NSSA area generates a special type of LSA known as LSA type 7. This type only exists in NSSA areas. Use the nssa option with the area OSPF subcommand to configure this feature in the Cisco ASA. The following is the command syntax:

 area area-id nssa [no-redistribution][default-information-originate [metric metric]

 [metric-type 1|2]][no-summary]

Example 6-17 demonstrates how to configure the Cisco ASA as an NSSA router and generate a default route.

Example 6-17. NSSA Configuration Example

router ospf 1

 network 192.168.4.1 255.255.255.255 area 1

 area 1 nssa default-information-originate

The highlighted line in Example 6-17 specifies area 1 as an NSSA and enables the Cisco ASA to inject a default route.

ABR Type 3 LSA Filtering

To filter type 3 LSAs in the Cisco ASA, use the prefix-list command. Once configured, the Cisco ASA can control which prefixes are sent from one area to another. The syntax of the prefix-list command is as follows:

 prefix-list list-name [seq seq-value] {deny | permit prefix/length} [ge min-value]

 [le max-value]

Table 6-3 lists all the options of the prefix-list command.

Table 6-3. prefix-list Command Options

Option	Description
list-name	Name of the prefix list
seq	The sequence number for the prefix list entry
seq-value	The sequence number value
deny	Denies access for a matching condition
permit	Permits access for a matching condition
prefix/length	The network number and length (in bits) of the network mask
ge	Applies the ge (greater or equal) value to the range specified
min-value	Specifies the lesser value of a range (the "from" portion of the range description); range is 0 to 32
le	Applies the le (less or equal) value to the range specified
max-value	Specifies the greater value of a range (the "to" portion of the range description); range is 0 to 32

Tip

You can enter a description (up to 225 characters) for each prefix list by using the prefix-list list-name description command.

Example 6-18 demonstrates how to configure a prefix list to filter type 3 LSAs.

Example 6-18. Type 3 LSA Filtering Configuration Example

prefix-list myfilter1 seq 5 deny 192.168.3.3/32

prefix-list myfilter2 seq 5 deny 192.168.1.1/32

prefix-list myfilter2 seq 10 permit 192.168.2.2/32

prefix-list myfilter2 seq 15 permit 192.168.1.0/24

router ospf 1

 network 192.168.10.0 255.255.255.0 area 1

 network 192.168.3.0 255.255.255.0 area 0

 area 1 filter-list prefix myfilter2 in

 area 1 filter-list prefix myfilter1 out

In Example 6-18, two prefix lists are configured. One is applied inbound and one outbound under the OSPF process. Each prefix list entry is identified with a sequence number. Notice that for the prefix list myfilter2, three sequence numbers are used to identify each entry (5, 10, and 15). When multiple entries of a prefix list match a given prefix, the entry with the lowest sequence number is matched first. In this case, the entry with sequence number 5 will be matched before the other two.

The Cisco ASA begins the search at the top of the prefix list. Once a match or deny occurs, the Cisco ASA does not need to go through the rest of the prefix list.

Tip

For efficiency, you may want to put the most common matches or denials near the top of the list, using the seq-value argument in the prefix-list command.

In Example 6-18, 192.168.3.3/32 will not be advertised, and any routes received for 192.168.1.1/32 will be dropped. On the other hand, 192.168.2.2/32 and the rest of the 192.168.1.0/24 network will be permitted.

OSPF neighbor Command and Dynamic Routing over VPN

OSPF Hello messages are sent over multicast by default. However, IPSec does not support multicast over a VPN tunnel. Consequently, OSPF adjacency using multicast cannot be established over IPSec VPN tunnels. Cisco ASA provides a solution to this problem by supporting the configuration of statically defined neighbors with the neighbor command. With the neighbor command, the Cisco ASA communicates with its peers using the unicast packets. This allows the OSPF messages to be successfully encrypted and sent over the VPN tunnel. This is similar to the neighbor command in Cisco IOS routers.

Note

Chapter 15 covers site-to-site IPSec VPNs.

The OSPF neighbors can be defined only on nonbroadcast media. Because the underlying physical media is Ethernet (broadcast), the media type must be changed to nonbroadcast under the interface configuration. This would override the default physical broadcast media type. Example 6-19 demonstrates how to use the neighbor command for an IPSec peer located at 209.165.200.225.

Example 6-19. OSPF neighbor Command Example

Chicago(config)# router ospf 1

Chicago(config-router)# neighbor 209.165.200.225 interface outside

INFO: Neighbor command will take effect only after OSPF is enabled

and network-type is configured on the interface

Notice the warning message in Example 6-19. The command will not take effect until the network type is changed to nonbroadcast under the interface. Use the ospf network point-to-point non-broadcast interface command to accomplish this. Example 6-20 demonstrates this command.

Example 6-20. Changing the Default Physical Media Type to Nonbroadcast

Chicago(config-router)# interface GigabitEthernet0/0

Chicago(config-if)# ospf network point-to-point non-broadcast

Additionally, OSPF expects neighbors to belong to the same subnet. The subnet requirement is overlooked for point-to-point links. Because the IPSec site-to-site VPN tunnels are considered a point-to-point connection, the previous command provides the solution to this problem. Only one neighbor can be configured on a point-to-point link.

Note

Once an interface is declared to be a point-to-point nonbroadcast link, it cannot form adjacencies unless neighbors are configured explicitly.

If OSPF is configured to run over a site-to-site IPSec tunnel, then that same interface cannot form an OSPF neighbor with the directly connected router.

On IPSec site-to-site and remote-access VPN configurations, you can optionally use reverse route injection (RRI). RRI is a feature on the Cisco ASA that provides a solution for topologies that require encrypted traffic to be diverted to the Cisco ASA and all other traffic to be sent to a separate router. In other words, RRI eliminates the need to manually define static routes on internal routers or hosts to be able to send traffic to remote site-to-site connections or remote-access VPN connections. RRI is not required if the Cisco ASA is used as the default gateway and all traffic passes through it to get into and out of the network.

Note

RRI is covered in detail in Chapter 15, "Site-to-Site IPSec VPN," and Chapter 16, "Remote Access VPNs."

There are several advantages to running OSPF over an IPSec VPN tunnel instead of using RRI. One of the major advantages is that when RRI is used, the routes to the remote networks or hosts are always advertised to the internal network, regardless of whether or not the VPN tunnel is operational. When using OSPF over an IPSec site-to-site tunnel, the routes to the remote networks or hosts are advertised only if the VPN tunnel is operational.

Troubleshooting OSPF

This section includes many mechanisms and techniques that are used to troubleshoot OSPF problems, such as several show and debug commands.

Useful Troubleshooting Commands

A commonly used command is show ospf [process-id]. It displays general information about OSPF routing-process IDs. The process-ID option displays information for a specific OSPF routing process. Example 6-21 shows the output of this command.

Example 6-21. Output of the show ospf [process-id] Command

Chicago# show ospf 1

 Routing Process "ospf 1" with ID 192.168.10.1 and Domain ID 0.0.0.1

 Supports only single TOS(TOS0) routes

 Does not support opaque LSA

 SPF schedule delay 5 secs, Hold time between two SPFs 10 secs

 Minimum LSA interval 5 secs. Minimum LSA arrival 1 secs

 Number of external LSA 0. Checksum Sum 0x 0

 Number of opaque AS LSA 0. Checksum Sum 0x 0

 Number of DCbitless external and opaque AS LSA 0

 Number of DoNotAge external and opaque AS LSA 0

 Number of areas in this router is 1. 1 normal 0 stub 0 nssa

 External flood list length 0

 Area BACKBONE(0)

 Number of interfaces in this area is 1

 Area has no authentication

 SPF algorithm executed 5 times

 Area ranges are

 Number of LSA 3. Checksum Sum 0x 1da9c

 Number of opaque link LSA 0. Checksum Sum 0x 0

 Number of DCbitless LSA 0

 Number of indication LSA 0

 Number of DoNotAge LSA 0

 Flood list length 0

As demonstrated in Example 6-21, the show ospf command gives you details about the OSPF configuration, LSA information, OSPF router ID, and number of areas configured in the Cisco ASA.

To display OSPF-related interface information, use the show ospf interface command. Example 6-22 includes the output of this command for the inside interface.

Example 6-22. Output of the show ospf interface Command

Chicago# show ospf interface inside

inside is up, line protocol is up

 Internet Address 192.168.10.1 mask 255.255.255.0, Area 0

 Process ID 1, Router ID 192.168.10.1, Network Type BROADCAST, Cost: 10

 Transmit Delay is 1 sec, State BDR, Priority 1

 Designated Router (ID) 192.168.10.2, Interface address 192.168.10.2

 Backup Designated router (ID) 192.168.10.1, Interface address 192.168.10.1

 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

 Hello due in 0:00:00

 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 0 msec

 Neighbor Count is 1, Adjacent neighbor count is 1

 Adjacent with neighbor 192.168.10.2 (Designated Router)

 Suppress hello for 0 neighbor(s)

The output of the show ospf interface command shows not only information about the OSPF communication on that specific interface, but also other information, such as the network type, cost, designated router information, etc.

To display OSPF neighbor information, use the show ospf neighbor command. The following is the command syntax:

 show ospf neighbor [interface-name] [neighbor-id] [detail]

To show neighbor information on a per-interface basis, use the interface-name argument. Use the neighbor-id option to display information about a specific neighbor, and use the detail option to display detailed neighbor information. The interface-name and neighbor-id options are mutually exclusive. Example 6-23 shows the output of the show ospf neighbor command.

Example 6-23. Output of the show ospf neighbor Command

Chicago# show ospf neighbor

Neighbor ID Pri State Dead Time Address Interface

192.168.10.2 1 FULL/DR 0:00:34 192.168.10.2 inside

When OSPF adjacency is formed, the Cisco ASA goes through several state changes before it becomes fully adjacent with its neighbor. The information that these states represent is crucial when troubleshooting OSPF problems in the Cisco ASA. These states are as follows:

• Down The first OSPF neighbor state. It means that no Hello packets have been received from this neighbor, but Hello packets can still be sent to the neighbor in this state.
• Attempt Only valid for manually configured neighbors in a non-broadcast multi-access (NBMA) environment. In Attempt state, the Cisco ASA sends unicast Hello packets every poll interval to the neighbor, if it has not received any Hello packets within the dead interval.
• Init Specifies that the Cisco ASA has received a Hello packet from its neighbor, but the receiving router's ID was not included in the Hello packet. When the Cisco ASA or any router running OSPF receives a Hello packet from a neighbor, it should send its router ID in the Hello packet as an acknowledgment that it received a valid Hello packet.
• 2Way Designates that bidirectional communication has been established between the Cisco ASA and its neighbor.
• Exstart The Cisco ASA is exchanging information to select who will be the DR and BDR (master-slave relationship) and chooses the initial sequence number for adjacency formation. The device with the higher router ID becomes the master and starts the exchange and, as such, is the only device that can increment the sequence number.
• Exchange Indicates the exchange of database descriptor (DBD) packets. Database descriptors contain LSA headers only and describe the contents of the entire link-state database.
• Loading The Cisco ASA is doing the actual exchange of link-state information with its neighbor.
• Full The Cisco ASA and its neighbor are fully adjacent with each other. All the router and network LSAs are exchanged and the routing databases are fully synchronized.

Example 6-24 shows the output of the show ospf neighbor command with the detail option. The neighbor in this example is a router with IP address 192.168.10.2. In this example, you can see that the OSPF state is Full and that there were six state changes. Additionally, you can see that the neighbor has been up for 26 minutes and 21 seconds.

Example 6-24. Output of the show ospf neighbor detail Command

Chicago# show ospf neighbor inside 192.168.10.2 detail

 Neighbor 192.168.10.2, interface address 192.168.10.2

 In the area 0 via interface inside

 Neighbor priority is 1, State is FULL, 6 state changes

 DR is 192.168.10.2 BDR is 192.168.10.1

 Options is 0x2

 Dead timer due in 0:00:31

 Neighbor is up for 00:26:21

 Index 1/1, retransmission queue length 0, number of retransmission 1

 First 0x0(0)/0x0(0) Next 0x0(0)/0x0(0)

 Last retransmission scan length is 1, maximum is 1

 Last retransmission scan time is 0 msec, maximum is 0 msec

Use the show ospf database command to display information related to the Cisco ASA OSPF database. The command displays information about the different OSPF LSAs. It displays detailed information about the neighbor router and the state of the neighbor relationship. Example 6-25 shows the output of the show ospf database command.

Example 6-25. Output of the show ospf database Command

Chicago# show ospf database

 OSPF Router with ID (192.168.10.1) (Process ID 1)

 Router Link States (Area 0)

Link ID ADV Router Age Seq# Checksum Link count

192.168.10.1 192.168.10.1 1943 0x80000005 0x99dd 1

192.168.10.2 192.168.10.2 20 0x80000003 0xa1d2 1

 Net Link States (Area 0)

Link ID ADV Router Age Seq# Checksum

192.168.10.2 192.168.10.2 1944 0x80000001 0xa2e6

 Type-5 AS External Link States

Link ID ADV Router Age Seq# Checksum Tag

192.168.20.0 192.168.10.2 19 0x80000001 0xfa25 0

192.168.13.0 192.168.10.2 19 0x80000001 0x8293 0

192.168.10.0 192.168.10.2 19 0x80000001 0xa72c 0

As demonstrated in Example 6-25, several external routes are learned from router 192.168.10.2. The 192.168.10.2 neighbor is advertising two routes for networks 192.168.20.0/24 and 192.168.13.0/24. Example 6-26 shows the output of the show route command for this example.

Example 6-26. Output of the show route Command

Chicago# show route

S 0.0.0.0 0.0.0.0 [1/0] via 209.165.200.226, outside

C 209.165.200.224 255.255.255.224 is directly connected, outside

C 192.168.10.0 255.255.255.0 is directly connected, inside

O E2 192.168.20.0 255.255.255.0 [110/10] via 192.168.10.2, 0:00:04, inside

O E2 192.168.13.0 255.255.255.0 [110/10] via 192.168.10.2, 0:00:04, inside

Tip

Make sure that the exact subnet mask is configured on the interfaces that are running OSPF between the Cisco ASA and its neighbor. A subnet mismatch creates a discrepancy in the OSPF database that prevents routes from being installed in the routing tables. Furthermore, the maximum transmission unit (MTU) size must also match between peers.

Table 6-4 lists some of the common reasons why OSPF neighbors have problems forming an adjacency and suggests the show commands that you can use to troubleshoot the problem.

Table 6-4. OSPF Common Problems and Useful show Commands

Problem	Command
OSPF is not enabled on an interface where it is needed.	show ospf interface
OSPF Hello or dead timer interval values are mismatched.	show ospf interface
OSPF network-type mismatch on the adjoining interfaces.	show ospf interface
OSPF area type is stub on one neighbor, but the adjoining neighbor in the same area is not configured for stub.	show ospf interface
OSPF neighbors have duplicate router IDs.	show ospf
OSPF Hellos are not processed due to a lack of resources, such as high CPU utilization or not enough memory.	show memory show cpu usage
Neighbor information is incorrect.	show ospf neighbor
An underlying layer problem is preventing OSPF Hellos from being received.	show ospf neighbor show ospf interface show interface

The debug ospf command is extremely useful for troubleshooting OSPF problems. However, only turn on debugs commands if any of the show commands discussed cannot help you solve the problem. Table 6-5 lists all the options of the debug ospf command.

Table 6-5. debug ospf Options

Option	Description
adj	Outputs information about the adjacency process transactions
database-timer	Outputs database timer information
events	Outputs OSPF transaction event information
flood	Includes OSPF flooding information
lsa-generation	Outputs OSPF LSA generation information
packet	Outputs detailed OSPF packet information
retransmission	Provides information about retransmissions during OSPF transactions
spf external	Outputs SPF information external to local area
spf internal	Outputs SPF information within a given area
spf intra	Outputs SPF intra-area information

Tip

If the debug ospf command is entered without any options, all options are enabled by default. This may not be appropriate for busy OSPF networks.

Example 6-27 shows the output of the debug ospf events command during a new adjacency. The first highlighted line shows that a two-way communication has been started to the router 192.168.10.2 on the inside interface and the state is 2WAY. The second highlighted line shows that NBR negotiation has been completed and the Cisco ASA is classified as the slave. The third and fourth highlighted lines indicate that the exchange has been completed and that the state is now FULL.

Example 6-27. Output of the debug ospf events Command

OSPF: Rcv DBD from 192.168.10.2 on inside seq 0x167f opt 0x2 flag 0x7 len 32 mtu

 1500 state INIT

OSPF: 2 Way Communication to 192.168.10.2 on inside, state 2WAY

OSPF: Neighbor change Event on interface inside

OSPF: DR/BDR election on inside

OSPF: Elect BDR 192.168.10.2

OSPF: Elect DR 192.168.10.1

 DR: 192.168.10.1 (Id) BDR: 192.168.10.2 (Id)

OSPF: Send DBD to 192.168.10.2 on inside seq 0x7c1 opt 0x2 flag 0x7 len 32

OSPF: NBR Negotiation Done. We are the SLAVE

OSPF: Send DBD to 192.168.10.2 on inside seq 0x167f opt 0x2 flag 0x2 len 132

OSPF: Rcv DBD from 192.168.10.2 on inside seq 0x1680 opt 0x2 flag 0x3 len 152 mtu

 1500 state EXCHANGE

OSPF: Send DBD to 192.168.10.2 on inside seq 0x1680 opt 0x2 flag 0x0 len 32

OSPF: Rcv hello from 192.168.10.2 area 0 from inside 192.168.10.2

OSPF: Neighbor change Event on interface inside

OSPF: DR/BDR election on inside

OSPF: Elect BDR 192.168.10.2

OSPF: Elect DR 192.168.10.1

 DR: 192.168.10.1 (Id) BDR: 192.168.10.2 (Id)

OSPF: End of hello processing

OSPF: Rcv DBD from 192.168.10.2 on inside seq 0x1681 opt 0x2 flag 0x1 len 32 mtu

 1500 state EXCHANGE

OSPF: Exchange Done with 192.168.10.2 on inside

OSPF: Synchronized with 192.168.10.2 on inside, state FULL

OSPF: Send DBD to 192.168.10.2 on inside seq 0x1681 opt 0x2 flag 0x0 len 32

OSPF: service_maxage: Trying to delete MAXAGE LSA

OSPF: Rcv hello from 192.168.10.2 area 0 from inside 192.168.10.2

OSPF: End of hello processing

 

Mismatched Areas

Example 6-28 shows the output of the debug ospf events command during an OSPF transaction where the Cisco ASA was configured with area 0 and the adjacent router was configured with area 1. Consequently, the mismatch area message is displayed in the debug output.

Example 6-28. Mismatched OSPF Areas

OSPF: Rcv pkt from 192.168.10.2, inside, area 0.0.0.0

 mismatch area 0.0.0.1 in the header

 

OSPF Authentication Mismatch

Here is an example in which the Cisco ASA was configured to perform OSPF authentication. OSPF authentication was not enabled on the neighbor router. Example 6-29 shows the output of the debug ospf event command.

Example 6-29. Mismatched OSPF Authentication Parameters

Chicago# debug ospf event

OSPF: Rcv pkt from 192.168.10.2, inside : Mismatch Authentication type. Input packet

specified type 0, we use type 1

Chicago#

 

Troubleshooting Virtual Link Problems

To display parameters and the current state of OSPF virtual links configured in the Cisco ASA, use the show ospf virtual-links command. Example 6-30 shows the output of the show ospf virtual-links command while the state of the virtual link to router 192.168.10.2 is down.

Example 6-30. Output of the show ospf virtual-links Command During a Configuration Mismatch in the Neighbor Router

Chicago# show ospf virtual-links

Virtual Link dmz to router 192.168.3.1 is down

 Run as demand circuit

 DoNotAge LSA allowed.

 Transit area 1, via interface dmz, Cost of using 10

 Transmit Delay is 1 sec, State DOWN,

 Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5

The problem is a configuration error on the Cisco ASA's neighbor router. The administrator notices, by looking at the running configuration with the show running-config command, that the router does not have the Cisco ASA router ID in its configuration.