Configuring OSPF Plaintext Authentication

Learn to configure, verify, and troubleshoot Cisco IOS OSPF simple password authentication, including interface and area-wide settings.

Overview

OSPF (Open Shortest Path First) is a link-state interior gateway protocol. Routers use Hello packets to discover neighbors and maintain relationships, then exchange link-state information to synchronize their databases. An OSPF adjacency is a neighbor relationship in which routers exchange and synchronize OSPF routing information.

OSPF plaintext authentication, also called simple password authentication, adds a shared-secret check to Hello packets and other OSPF protocol exchanges. Both routers on the same OSPF segment must use a compatible authentication type and the same password before they can form an adjacency.

Why Authenticate OSPF Neighbors?

Without authentication, an unauthorized device that can reach an OSPF segment may attempt to form an adjacency and inject routing information. Authentication helps ensure that a device knows the shared secret before its OSPF packets are accepted as part of the neighbor relationship.

Authentication does not replace normal OSPF checks. Routers must still agree on items such as the area, subnet, Hello and dead timers, network type, and other adjacency parameters. Authentication is one compatibility requirement among several.

Authentication is local to the OSPF segment or area where it is configured. Enabling it on one router does not automatically configure the other router. Every neighbor on an authenticated segment needs compatible settings.

OSPF Authentication Types

Authentication type	Cisco IOS configuration approach	Password protection	Typical use	Security recommendation
None, type 0	No authentication requirement	No shared password	Default behavior and networks where authentication is not configured	Use only when the surrounding network controls provide sufficient protection.
Simple password, type 1	`ip ospf authentication` and `ip ospf authentication-key`, or area authentication with interface keys	Password is not cryptographically protected	Labs, basic training, and legacy compatibility	Do not treat it as encryption; avoid it for production when stronger options are available.
Cryptographic message digest, type 2	Commonly configured with message-digest interface commands	Uses a cryptographic digest rather than sending the password as simple authentication data	Networks requiring stronger OSPF authentication	Prefer an appropriate cryptographic method, such as supported MD5 authentication, over simple passwords.

The authentication type is a field in the OSPF packet that identifies whether authentication is disabled, simple-password based, or cryptographic. Simple password authentication uses type 1. Type 2 is commonly associated with legacy MD5 authentication; newer platform capabilities and security policies may provide other cryptographic choices.

How Simple Password Authentication Works

With simple authentication, each router places the configured shared password into the OSPF authentication data field. The field supports a maximum of 8 characters for this authentication method. The receiving router compares the value with its own configured key.

The authentication type must match on both ends.
The password must match exactly, including capitalization.
A password longer than 8 characters is not a valid choice for the simple-password field; use a short test key in a lab.
The authentication password is independent of the OSPF process ID, area ID, router ID, and interface IP address.

For example, router ospf 1 uses process ID 1 locally. It does not mean that the neighbor must use process ID 1 because the process ID has only local significance. In contrast, both routers on a link must agree on the area and authentication settings. The interface IP addresses identify the network and endpoints; they are not authentication credentials.

Authentication Scope

Interface-level authentication

Interface authentication applies directly to an OSPF-enabled interface. This approach is useful when only selected links should use simple authentication, or when you want to make the policy explicit for each link.

interface GigabitEthernet0/0
 ip ospf authentication
 ip ospf authentication-key LABKEY1

The neighboring interface must use the same simple authentication mode and key. The key is configured on every applicable interface, not under the OSPF process as a single global password.

Area-wide authentication

Area authentication makes simple authentication a requirement for OSPF interfaces participating in a particular area. The area command enables the policy, but each applicable interface still receives its authentication key.

router ospf 1
 area 0 authentication
!
interface GigabitEthernet0/0
 ip ospf authentication-key LABKEY1

Area-wide enforcement can be easier to manage when all links in an area should follow the same policy. Interface-level configuration provides more selective control. Authentication enabled for area 0 does not automatically apply to area 10 or any other area.

Method	Where authentication is enabled	Where the password is configured	Operational effect	Best use case
Interface level	Directly under each OSPF-enabled interface	Under each participating interface	Only selected interfaces require the configured mode and key.	Selective link protection or small labs where link-by-link control is preferred.
Area level	Under the OSPF process with an area authentication command	Still under each applicable interface	Interfaces in the selected area are required to use authentication.	Consistent enforcement across many links in one area.

Configuration Workflow

Confirm IPv4 addressing and identify the interfaces that share OSPF segments.
Enable OSPF on the required interfaces using network statements or interface-based OSPF configuration.
Confirm that the connected routers use the same area, compatible subnet, and compatible OSPF network type assumptions.
Choose interface-level authentication or area-wide authentication.
Configure the same simple key on every pair of connected OSPF interfaces that requires authentication.
Verify neighbor formation and inspect the active interface configuration.
Save the running configuration after validation.

Example: Two-router point-to-point link

R1 and R2 are connected through Ethernet interfaces in subnet 192.0.2.0/30 and use OSPF area 0. The following example uses interface-level authentication. Apply equivalent settings to the corresponding interface on R2.

R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1
R1(config-router)# network 192.0.2.0 0.0.0.3 area 0
R1(config-router)# exit
R1(config)# interface GigabitEthernet0/0
R1(config-if)# ip ospf authentication
R1(config-if)# ip ospf authentication-key LABKEY1
R1(config-if)# end
R1# copy running-config startup-config

R2 must enable OSPF on its connected interface, place that interface in area 0, enable simple authentication, and configure LABKEY1. The OSPF process ID and router ID on R2 should be locally appropriate; router IDs must be unique.

Example: Area-wide authentication

For three routers with two links in area 10, enable authentication for area 10 and configure a key on every OSPF-facing interface in that area.

router ospf 1
 area 10 authentication
!
interface GigabitEthernet0/0
 ip ospf authentication-key AREAKEY1
!
interface GigabitEthernet0/1
 ip ospf authentication-key AREAKEY1

Every neighbor on both links must apply the same policy and matching key on its local interface. An area command on one router does not configure remote routers.

Verification

Check neighbor state

show ip ospf neighbor
show ip ospf neighbor detail

The relevant neighbor should progress to an established state, commonly FULL on point-to-point links. FULL means the OSPF databases have synchronized, subject to the network type and any DR/BDR roles. A neighbor that remains in a lower state or is absent requires further investigation.

Inspect interface authentication

show ip ospf interface GigabitEthernet0/0

Look for the interface's OSPF area, network type, timers, and an indication that simple password authentication is enabled. This command is especially useful for detecting an unexpected area or a missing authentication mode.

Inspect the applied configuration

show running-config interface GigabitEthernet0/0
show ip protocols

The interface configuration should show the intended authentication key and any interface-level authentication command. The protocol output helps confirm the OSPF process, participating networks, and area assignments.

Changing authentication on a live interface can reset an existing adjacency. The neighbor will return only after both endpoints again use compatible authentication settings and all other OSPF requirements are satisfied.

Troubleshooting

Symptom	Likely cause	Verification command	Corrective action
Neighbor absent after enabling authentication	Only one side requires authentication, or the authentication types differ.	`show ip ospf interface GigabitEthernet0/0`	Configure the same authentication mode on both ends, or remove the requirement consistently.
Authentication mismatch messages	Passwords differ, including case-sensitive spelling differences.	`show running-config interface GigabitEthernet0/0`	Set an identical valid key on both connected interfaces.
One side is configured and the other side is not	One interface uses type 1 while the other uses null authentication.	`show ip ospf interface GigabitEthernet0/0`	Coordinate the change so both routers use the same authentication policy.
Password exceeds supported length	The simple-password field supports no more than 8 characters.	`show running-config interface GigabitEthernet0/0`	Use a matching key of 8 characters or fewer; plan stronger authentication for production.
Credentials match but adjacency still fails	Another OSPF compatibility requirement is wrong.	`show ip ospf neighbor detail` and `show ip ospf interface`	Check area, subnet, timers, MTU, network type, passive status, and router IDs.

Common authentication failures

Password mismatch: LABKEY1 and LABKEY2 are different. Correct the key on one side and allow the adjacency to renegotiate.
Case mismatch: LabKey1 is not the same as LABKEY1.
Null versus simple authentication: one router accepts unauthenticated packets while the other expects type 1 packets.
Area omission: area-wide authentication is configured, but an interface has no local key or is not actually participating in the expected area.
Configuration conflict: interface-level settings and area-level enforcement do not produce the intended policy. Inspect the effective interface output rather than assuming the process configuration is sufficient.

Authentication versus unrelated adjacency problems

Matching credentials do not guarantee adjacency. Compare the following before repeatedly changing authentication:

OSPF area IDs and interface area membership
IP subnet membership and interface addressing
Hello and dead timers
MTU and OSPF network type
Passive-interface settings
Unique router IDs
Expected DR/BDR behavior on multiaccess networks

Use debugging carefully

debug ip ospf adj
debug ip ospf hello
undebug all

Use debugging briefly, preferably in a lab or controlled maintenance window. Adjacency and Hello debugging can produce substantial output on busy devices. Debug messages may identify authentication rejection or a parameter mismatch, but do not copy sensitive credentials into tickets, chat, or shared logs. After collecting the needed evidence, use undebug all to stop debugging.

Password Mismatch Recovery Example

Suppose R1 uses LABKEY1 and R2 uses LABKEY2 on the same segment. The routers may exchange packets, but authentication fails and the neighbor does not reach FULL.

R1# show running-config interface GigabitEthernet0/0
...
 ip ospf authentication
 ip ospf authentication-key LABKEY1
!
R2# show running-config interface GigabitEthernet0/0
...
 ip ospf authentication
 ip ospf authentication-key LABKEY2

Change one side to the agreed key, then verify recovery:

R2(config)# interface GigabitEthernet0/0
R2(config-if)# ip ospf authentication-key LABKEY1
R2(config-if)# end
R2# show ip ospf neighbor

The adjacency may briefly reset during the change. Once both sides match and no other OSPF requirement is incorrect, the neighbor should return to FULL where that state is expected.

Security and Migration Guidance

Clear-text authentication confirms knowledge of a shared value, but it does not conceal that value. Someone able to observe the relevant OSPF traffic may recover the password. It also does not provide the broader security properties expected from modern cryptographic protection.

Prefer cryptographic OSPF authentication, such as supported message-digest authentication, where appropriate.
Use unique keys for separate environments and avoid reusing operational passwords.
Keep simple keys short enough for the type 1 field, but do not mistake a complex-looking short key for encryption.
Plan key changes and authentication-type changes as coordinated network operations.
Change all affected neighbors in a controlled sequence to limit routing disruption.

Changing from null to simple authentication, from simple to cryptographic authentication, or between incompatible cryptographic settings can remove adjacencies until every affected endpoint is updated. Test the migration in a lab and schedule coordinated production changes.

Exam-Relevant Notes

OSPF simple password authentication is type 1.
The simple authentication password is limited to 8 characters.
The password must match on neighboring interfaces, including capitalization.
Interface-level authentication is configured under the interface; area-wide enforcement is configured under the OSPF process.
Area authentication does not automatically configure the password on each interface.
The OSPF process ID is locally significant and is not the shared authentication password.
Authentication compatibility is necessary but not sufficient for a FULL adjacency.
Simple password authentication is not encryption; cryptographic authentication is preferred for production where supported.