OSPF on the Cisco ASA: Areas, Redistribution, and the ASA's Quirks

OSPF is the dynamic routing protocol you are most likely to meet on a Cisco ASA. When a firewall needs to learn more than a handful of internal prefixes and the core already speaks OSPF, running it on the ASA is a defensible choice. This article is the full build: configuration, a verified adjacency with MD5 authentication, the DR/BDR election the firewall loses, the link-state database, and redistribution, all captured from a live ASAv. It sits in our Cisco ASA cluster, and if you want OSPF theory beyond the firewall specifics, the OSPF pillar covers areas, LSA types, and metrics in depth.

One honesty note up front, because credibility matters: every capture below came from an ASAv 9.24(1) running in Cisco Modeling Labs, driven over SSH from a real Linux host. The peer, CORE1, is an IOS-XE router. This is a real adjacency between an ASA and an IOS router with cryptographic authentication turned on, not a diagram.

The configuration, and the two things IOS people get wrong

Here is the OSPF configuration on our firewall, FW1. Read it, then note the two differences from IOS that catch everyone:

interface GigabitEthernet0/1
 ospf message-digest-key 1 md5 <key>
router ospf 1
 router-id 10.20.10.1
 network 10.20.10.0 255.255.255.0 area 0
 area 0 authentication message-digest
 redistribute static subnets

First, there is no ip keyword. On IOS the interface command is ip ospf message-digest-key; on the ASA it is simply ospf message-digest-key. Second, the network statement takes a real subnet mask, 255.255.255.0, not an IOS wildcard of 0.0.0.255. Type a wildcard here and you will either be rejected or match nothing, and the adjacency will never form. For the record, the matching side on CORE1 (which is IOS) uses ip ospf message-digest-key and area 0 authentication message-digest, so the two boxes meet in the middle: same MD5 key, same key ID, same area authentication mode, different command prefixes.

The area 0 authentication message-digest line turns on MD5 authentication for the whole area, and the interface message-digest-key 1 md5 line supplies the actual key with key ID 1. Both ends must agree on the key ID and the key string, or the neighbours will see each other's hellos and refuse to become adjacent.

Proving the adjacency and the authentication

With the config in place, the neighbour comes up. On the ASA you check it with show ospf neighbor (again, no ip):

FW1# show ospf neighbor
Neighbor ID     Pri   State           Dead Time   Address         Interface
10.255.0.1        1   FULL/DR         0:00:30     10.20.10.2      inside

The state is FULL, which is the goal. Anything less (INIT, 2-WAY, EXSTART, EXCHANGE, LOADING) means the adjacency is stuck partway and you have work to do. The /DR tells you the neighbour is the Designated Router on this segment, which we will come back to. But the single most useful command for confirming that authentication is actually working is show ospf interface:

FW1# show ospf interface inside
inside is up, line protocol is up
  Internet Address 10.20.10.1 mask 255.255.255.0, Area 0
  Process ID 1, Router ID 10.20.10.1, Network Type BROADCAST, Cost: 10
  Designated Router (ID) 10.255.0.1, Interface address 10.20.10.2
  Backup Designated router (ID) 10.20.10.1, Interface address 10.20.10.1
  Timer intervals configured, Hello 10, Dead 40, Wait 40, Retransmit 5
  Supports Link-local Signaling (LLS)
  Cisco NSF helper support enabled
  IETF NSF helper support enabled
  Neighbor Count is 1, Adjacent neighbor count is 1
  Cryptographic authentication enabled
    Youngest key id is 1

The line that matters is near the bottom: Cryptographic authentication enabled, with Youngest key id is 1. That is the ASA confirming MD5 is active on this interface and telling you which key it is using. If you configure authentication and this line does not appear, the key never took, and you should assume the adjacency (if it even formed) is running unauthenticated. It is a small line that saves you from shipping a firewall you think is protected when it is not.

The DR/BDR election the ASA loses, and why

Look again at the show ospf interface output. The Designated Router is ID 10.255.0.1 (that is CORE1), and the Backup Designated Router is 10.20.10.1 (that is our firewall). The ASA lost the election and became the BDR. This is a genuinely useful thing to understand, so let us walk it.

On a broadcast segment, OSPF elects a DR and a BDR to reduce the number of adjacencies. The election is decided first by interface priority (higher wins), and only if priorities are tied does it fall to the highest router ID. Look at the neighbour output: both routers show priority 1, the default. Since neither box was configured with a higher OSPF priority, the priorities tie, and the tie-breaker is the router ID. CORE1's RID is 10.255.0.1; the firewall's is 10.20.10.1. As dotted-decimal values, 10.255.0.1 is higher than 10.20.10.1, so CORE1 wins the DR role and the ASA settles for BDR.

Why care? Because if you want the ASA to be the DR (or emphatically not the DR), priority is your lever, not router ID, and you set it per interface. And because a surprising number of "why is the wrong box the DR" tickets come down to exactly this: everyone left priority at the default, so the election silently fell through to router ID, and the box with the highest-numbered loopback or interface address won by accident. On a firewall specifically, you rarely want it carrying the DR workload of maintaining adjacencies with every router on a segment, so losing the election here is arguably the right outcome.

The ASA is a full OSPF participant, not a bystander

It is tempting to think of a firewall as a passive listener that just absorbs routes. It is not. The ASA originates its own Router LSA and participates fully in flooding. Here is the link-state database:

FW1# show ospf database

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

        Router Link States (Area 0)
Link ID         ADV Router      Age    Seq#       Checksum Link count
10.20.10.1      10.20.10.1      69     0x80000002 0x9ee4 1
10.255.0.1      10.255.0.1      70     0x80000005 0x5bff 3

        Net Link States (Area 0)
Link ID         ADV Router      Age    Seq#       Checksum
10.20.10.2      10.255.0.1      70     0x80000001 0x8947

Two Router LSAs are in the database, one advertised by each router. The row where both Link ID and ADV Router read 10.20.10.1 is the ASA's own Router LSA: the firewall is describing its links to the rest of the area, exactly like any router would. The Net Link State (a Network LSA) is advertised by 10.255.0.1, which is correct, because the DR originates the Network LSA for a broadcast segment, and CORE1 is the DR. So the database is internally consistent with the election we just walked through: CORE1 is DR, so CORE1 owns the Network LSA, and both boxes contribute their own Router LSAs.

A word on areas

Our lab keeps everything in area 0, the backbone, which is the right call for a single firewall attached to a single OSPF domain. The ASA supports the full area model: you can make it an Area Border Router by placing different interfaces in different areas, and it honours stub, totally stubby, and not-so-stubby (NSSA) area types the same way IOS does. On a firewall the most common non-backbone design is to place the segment behind the firewall in a stub or NSSA area so that external LSAs from the rest of the network do not flood into it, which keeps the firewall's database lean and reduces its exposure to churn elsewhere. If you do run the ASA as an ABR, remember that area authentication is configured per area (area 0 authentication message-digest only covers area 0), so each area you add needs its own authentication statement.

Redistributing static routes into OSPF

A firewall almost always has static routes (the default toward the ISP, routes into segments that do not run a protocol), and you frequently want those visible to the rest of the OSPF domain. The redistribute static subnets line does that. The subnets keyword matters: without it, classful behaviour kicks in and only classful networks get redistributed, silently dropping your subnetted routes. You can confirm what is actually configured with:

FW1# show run all router ospf | include redistribute
 no redistribute connected
 redistribute static subnets

This is a nice confirmation because show run all prints the defaults too, so you can see explicitly that connected redistribution is off (no redistribute connected) while static redistribution is on with subnets. When you redistribute, remember the routes enter OSPF as external (type E2 by default), which is a different LSA type and a different metric behaviour than internal routes. If a redistributed route is not showing up on the far side, checking whether subnets is present is the first thing to rule out.

When the adjacency will not come up

Most OSPF-on-ASA tickets are one of a small set of mismatches, and the show ospf interface output above hands you the values to check. Look at the timer line: Hello 10, Dead 40. Both neighbours must agree on the hello and dead intervals, or they will never progress past the two-way state. On a broadcast network these default to 10 and 40, so a mismatch usually means someone tuned one side and not the other.

The Network Type BROADCAST field is the next thing to confirm. If one side thinks the segment is broadcast and the other point-to-point, the DR/BDR expectations differ and the adjacency can hang in EXSTART. Then there is authentication: if you see the neighbour flapping or never leaving INIT after you turned on MD5, the key ID or the key string does not match, and the fix is to line them up on both ends. Finally, MTU. OSPF exchanges the interface MTU in the database description packets, and if the two interfaces disagree the adjacency parks in EXSTART or EXCHANGE indefinitely. It is a classic firewall-to-router gotcha because the two platforms sometimes default to different MTUs.

A quick mental checklist when an ASA OSPF neighbour is stuck: same area number, same hello and dead timers, same network type, same authentication key ID and string, same MTU, and the interface actually covered by a network statement. Run show ospf neighbor and read the state field. The state tells you roughly where in the process it is failing (INIT and two-way point at hello or authentication problems; EXSTART and EXCHANGE point at MTU or network-type problems), which is far faster than guessing.

OSPF on the ASA versus OSPF on IOS

Most of what you know about OSPF carries over. But the differences are exactly the things that waste an afternoon, so here they are side by side:

The passive-interface point deserves a word. The ASA does not passive its interfaces for you. Any interface whose subnet is covered by a network statement will try to form adjacencies. On a firewall that is a security consideration: you almost never want OSPF hellos leaving the outside interface toward the internet, so scope your network statements tightly and use passive-interface on anything facing untrusted networks. This is the same discipline covered in ASA management hardening, applied to the control plane.

Key Takeaways

• OSPF is the most common dynamic protocol on an ASA. The build is close to IOS but drops the ip keyword and uses a real subnet mask in the network statement.
• show ospf interface is your authentication check. The line Cryptographic authentication enabled with a key ID confirms MD5 is genuinely active, not just configured.
• The ASA lost the DR election to CORE1 because priorities tied at the default of 1, so the tie broke on router ID, and 10.255.0.1 outranks 10.20.10.1. Use interface priority, not router ID, to control the outcome.
• The ASA is a full participant: it originates its own Router LSA, visible in show ospf database. The DR (CORE1) owns the Network LSA.
• Use redistribute static subnets and keep the subnets keyword, or classful behaviour silently drops your subnetted statics.
• The ASA does not passive its interfaces for you. Scope network statements tightly and passive anything facing untrusted networks.
• For the wider protocol, see the OSPF pillar; for the rest of the firewall build, the Cisco ASA cluster.