CCNA Single-Area OSPFv2 and OSPFv3: Adjacencies, DR/BDR, Point-to-Point and Router ID

OSPF (Open Shortest Path First) is a link-state interior routing protocol: each router discovers neighbors with hello packets, forms adjacencies, exchanges link-state advertisements (LSAs) until every router in the area holds the same link-state database, and then runs the SPF algorithm to build its routes. In a single-area design every OSPF interface sits in one area, normally area 0 (the backbone). OSPFv2 carries IPv4; OSPFv3 carries IPv6. Both use the same neighbor states, network types, DR/BDR election and 32-bit router ID, so most of this lesson applies to both.

On IOS XE an OSPFv2 process is created with router ospf <process-id>. The process ID is a locally significant number: it identifies the process on this router only, is never sent in packets, and does not have to match the neighbor's. An interface joins the process in one of two ways:

• a network statement under the process, which matches interface addresses with a wildcard; or
• the interface command ip ospf <process-id> area <area-id>, entered on the interface itself.

router ospf 1
 router-id 1.1.1.1
 network 10.0.12.0 0.0.0.255 area 0
!
interface GigabitEthernet0/2
 ip ospf 1 area 0

Once an interface is enabled, OSPF does two separate things on it: it advertises the interface's connected subnet, and (unless the interface is passive) it sends hellos to look for neighbors. Keeping those two jobs apart answers most configuration questions in this topic.

A network statement enables OSPF on every interface whose primary IPv4 address falls inside the address and wildcard given, and places those interfaces in the named area. The wildcard is an inverse mask: a 0 bit must match, a 1 bit can be anything. network 192.168.8.0 0.0.7.255 area 0 therefore matches any interface address from 192.168.8.0 to 192.168.15.255, so an interface on 192.168.16.1 is not matched.

To choose a statement for a requirement such as "enable Gi0/0 and Gi0/1 but not Gi0/2", write each interface address in binary (or block sizes), find the smallest block that covers the wanted addresses, and check that the block excludes the unwanted one. A wildcard of 0.0.0.0 with the exact interface address is always precise; the address in the statement does not have to be a subnet ID.

What gets advertised

The network statement only selects interfaces. The prefix OSPF advertises comes from the interface's own address and mask, not from the statement. An interface addressed 10.44.7.65/26 matched by network 10.44.0.0 0.0.255.255 area 0 is advertised as 10.44.7.64/26, never as 10.44.0.0/16. (A loopback is advertised as a /32 host route by default.)

Network statement versus interface command

The interface command ip ospf <pid> area <area> enables that one interface with no wildcard maths. If both an interface command and a matching network statement apply to the same interface, the interface command takes precedence: an interface with ip ospf 1 area 7 is in area 7 even when a broad network statement for area 0 in the same process also matches its address. An interface can be in only one area per process. Note the different syntax for the other protocols: ipv6 ospf <pid> area <area> is OSPFv3, and ospfv3 <pid> ipv4|ipv6 area <area> is the OSPFv3 address-family form, not classic OSPFv2.

To check which interfaces are enabled, show ip ospf interface brief lists one line per OSPF interface with its process, area, address/mask, cost, state (DR, BDR, DROTH, P2P; WAIT during an election) and neighbor count (full/total). show ip protocols shows the network statements, the router ID and the passive interfaces.

A passive interface stays in OSPF, so its subnet is still advertised, but the router sends no hellos on it and processes none it receives, so no adjacency can form there. It is the right setting for a user LAN or a loopback with no OSPF neighbors: the subnet remains reachable from the rest of the network, while OSPF packets are not offered to hosts that have no use for them.

Two configuration styles exist under the routing process:

! one at a time
router ospf 1
 passive-interface GigabitEthernet0/2

! everything passive, then open the uplinks
router ospf 1
 passive-interface default
 no passive-interface GigabitEthernet0/0
 no passive-interface GigabitEthernet0/1

passive-interface default makes every OSPF interface passive, including any interface added later, so it suits a router with many LAN ports and few uplinks. The trap is that it also silences the uplinks: entering it alone drops every existing adjacency once the dead interval expires, while the LAN subnets (and the uplink subnets) stay in the router's own LSA. The fix is no passive-interface for each uplink, not removing the default, which would make the LANs active again.

A passive interface is easy to spot: show ip ospf interface prints No Hellos (Passive interface), and show ip protocols lists it under "Passive Interface(s)". If two routers on a link see no neighbor and one side shows that line, the cause is the passive setting on that side, and the fix is no passive-interface for that interface.

The router ID (RID) is a 32-bit number, written like an IPv4 address, that names the router in every hello and LSA. IOS picks it when the OSPF process starts, in this order:

1. the value of the router-id command under the process, if configured;
2. otherwise, the highest IPv4 address on a loopback interface that is up;
3. otherwise, the highest IPv4 address on any other interface that is up.

Loopbacks beat physical interfaces even when a physical address is numerically higher, and an interface that is administratively down is skipped. The RID does not have to be a reachable or advertised address; 1.1.1.1 is a perfectly good configured value.

The RID is sticky

Once chosen, the RID does not change while the process runs. Adding router-id, adding a loopback with a higher address, or shutting down the interface whose address was used leaves the current RID in place; IOS even prints a reminder to "reload or use clear ip ospf process" for a new router-id to take effect. The new value is used only after:

• clear ip ospf process (confirm the prompt), which restarts OSPF and briefly drops this router's adjacencies; or
• a reload with the configuration saved.

Anything short of restarting the OSPF process itself leaves the RID unchanged, because the RID is chosen only at process start. show ip protocols and show ip ospf show the RID in use.

Duplicate router IDs

Router IDs must be unique. A router that receives a hello carrying its own RID logs a duplicate router ID message and does not form the adjacency. This is common when a configuration template is reused. Because a RID changes only on the router whose OSPF process restarts, the fix has two parts on the same router: configure a new, unique router-id on the router that should change, then restart OSPF there (clear ip ospf process, or a reload, which is more disruptive). Restarting the process on a router whose RID you did not change achieves nothing.

Two routers become neighbors only if the hellos they exchange agree on a set of parameters; a hello that fails a check is silently discarded, so the routers simply never list each other. Other settings are local and may differ freely.

Two further settings are not hello checks but still break the relationship: the interface MTU, which is checked in database description packets (next section), and the network type, which does not stop an adjacency but does stop routes being installed (see the point-to-point section).

Timers

On Ethernet (broadcast and point-to-point network types) the defaults are a 10-second hello and 40-second dead interval. If you set only ip ospf hello-interval, IOS derives the dead interval as four times the hello: hello-interval 3 gives 3/12. A timer mismatch is fixed by making both values agree, either by setting the same values on the other side or by removing the non-default command so the defaults return; changing only one of the two values leaves the other mismatched. show ip ospf interface prints the configured "Hello, Dead, Wait" values.

Area and subnet

An area mismatch (one side's interface in area 0, the other in area 1) causes the hellos to be discarded, so show ip ospf neighbor has no entry for the other router at all, not a stuck state. On a broadcast link OSPFv2 also requires the same subnet and mask: 192.168.50.1/26 and 192.168.50.2/27 on the same segment never become neighbors, even though both addresses may be matched by the same network statement. The check compares interface masks, so the network statement's wildcard plays no part in it.

An OSPF neighbor moves through states shown in the State column of show ip ospf neighbor (followed by the neighbor's role, such as FULL/DR):

INIT: one-way hellos

A neighbor stuck in INIT means this router hears the other, but the other does not hear this router. The usual cause is a filter on one side. If R2 drops R1's hellos with an inbound ACL, R2 has no entry for R1, while R1 receives R2's hellos, which do not list R1, so R1 shows R2 as INIT. OSPF is not TCP or UDP: it is IP protocol 89, so the ACL needs permit ospf any any (or equivalent). Permitting only hellos to 224.0.0.5 is not enough on a broadcast link, because the DBD and LSR packets of the database exchange (and direct acknowledgements) are sent unicast to the neighbor's address, and updates and delayed acknowledgements also use 224.0.0.6.

EXSTART/EXCHANGE: MTU mismatch

Each DBD packet carries the sender's interface MTU. A router rejects a DBD whose MTU is larger than its own interface can receive, so when one side has ip mtu 1492 and the other uses 9000 (jumbo frames), the database exchange never completes and the neighbor stays in EXSTART or EXCHANGE. The smaller-MTU router is the one rejecting. Fixes, in order of preference:

• match the MTU on both interfaces (raise the smaller side or lower the larger one, whichever the link and design support); or
• ip ospf mtu-ignore on the router that is rejecting the DBDs (the smaller-MTU side), which skips the MTU check. Configuring it on the larger-MTU side does not help, because that router was not rejecting anything.

Reaching EXSTART at all proves the hellos already agree, so the cause lies in the database exchange, not in anything the hello checks compare.

2WAY: not always a fault

On a broadcast segment, DROTHERs form FULL adjacencies only with the DR and BDR. Two DROTHERs stop at 2WAY/DROTHER with each other permanently, and that is normal. A router that lists the DR and BDR as FULL and the other routers as 2WAY/DROTHER is itself a DROTHER; it learns those routers' LSAs through the DR. Do not read a stable 2WAY as a timer or MTU problem: a timer mismatch would leave no neighbor entry at all, and an MTU problem stalls in EXSTART/EXCHANGE.

On a broadcast network type (the default on Ethernet), OSPF elects a designated router (DR) and a backup designated router (BDR) so that every router forms full adjacencies with just those two instead of with every other router on the segment. The election uses:

1. the highest interface priority (ip ospf priority, 0 to 255, default 1);
2. on a tie, the highest router ID.

Interface IP addresses play no part. A router with priority 0 is ineligible: it never becomes DR or BDR, yet it still forms adjacencies with the DR and BDR and exchanges routes normally. That makes priority 0 the setting for keeping a router out of the election, configured on that router alone. Because priority is compared before the router ID, a RID value can only decide between routers that tie on priority.

Worked example: RA (RID 8.8.8.8, priority 1), RB (1.1.1.1, priority 50), RC (6.6.6.6, priority 0) and RD (5.5.5.5, priority 1) start together. RC is out of the running. RB has the highest priority, so it is DR despite the lowest RID. RA and RD tie on priority 1, so the higher RID decides: RB is DR and RA is BDR, and RC and RD are DROTHERs.

The election is not preemptive

The election happens when routers come up on the segment (after a wait equal to the dead interval). Once a DR and BDR exist, a newly arriving router, even one with priority 255 or a higher RID, becomes a DROTHER; raising a priority on a running router changes nothing either. Roles change only when a DR or BDR fails or its OSPF process restarts:

• if the DR fails, the BDR becomes DR, and a new BDR is elected among the remaining eligible routers by priority, then RID;
• when the old DR returns, it does not take its role back; it joins as a DROTHER.

The same logic covers a BDR failure: the DR keeps its role and a new BDR is elected. Example: RA is DR, RB is BDR, RC (priority 1, RID 10.0.0.9) and RD (priority 5, RID 10.0.0.1) are DROTHERs. RB fails: RA stays DR, RD becomes BDR because priority beats RID, and RB returns as a DROTHER. To force a particular DR you set priorities and then restart OSPF on the segment's routers (or bring the current DR and BDR down), not just raise a priority.

OSPF uses two link-local multicast groups. AllSPFRouters is 224.0.0.5 in OSPFv2 and FF02::5 in OSPFv3; AllDRouters is 224.0.0.6 and FF02::6.

So when a DROTHER's link fails, it sends its updated LSA to 224.0.0.6; the DR then re-floods it to 224.0.0.5, and every router receives it. The BDR listens to 224.0.0.6 so it is ready to take over, but it does not re-flood while the DR is working. Only the .5 and .6 groups (FF02::5 and FF02::6) belong to OSPF; the other well-known 224.0.0.x and FF02:: groups serve other protocols or purposes. On a point-to-point network type there is no DR, so all multicast OSPF traffic uses 224.0.0.5.

The point-to-point network type treats a link as having exactly one neighbor, so OSPF holds no DR/BDR election and skips the election wait. Ethernet interfaces default to the broadcast type even when only two routers are connected, so on a dedicated router-to-router Ethernet link it is common to configure ip ospf network point-to-point on both ends.

A neighbor line such as 2.2.2.2 0 FULL/ - therefore means a point-to-point link with a complete adjacency; the 0 is not a configured priority and nothing is missing. The timers and the hello destination do not change when you switch Ethernet to point-to-point (the 30/120 timers belong to non-broadcast types).

Network type mismatch

The network type is not a hello check, so if one end is point-to-point and the other broadcast, the two (with matching 10/40 timers) still reach FULL. The output looks odd: the point-to-point side shows FULL/ -, while the broadcast side shows its neighbor in a DR or BDR role (for example FULL/BDR). The real damage is in the database: the two routers describe the link differently in their router LSAs (the broadcast side expects a DR-based transit network), so SPF cannot use the link and the routes learned over it are not installed. The fix is to make the network types match, normally ip ospf network point-to-point on the side still set to broadcast.

OSPFv3 is the OSPF version for IPv6. It keeps OSPFv2's states, network types, timers, DR/BDR election and 32-bit router ID, but it is enabled per interface and runs over link-local addresses. A minimal configuration needs three things:

ipv6 unicast-routing
!
ipv6 router ospf 1
 router-id 1.1.1.1
!
interface GigabitEthernet0/0
 ipv6 address 2001:DB8:12::1/64
 ipv6 ospf 1 area 0

• ipv6 unicast-routing in global configuration; without it the router does not route IPv6 (IOS also requires it before an OSPFv3 process can run). ip routing is the IPv4 equivalent and is already on.
• ipv6 ospf <pid> area <area> on each interface. There are no network statements in OSPFv3; the interface command is the only way to enable it. Passive interfaces work as in OSPFv2 (passive-interface under ipv6 router ospf).
• A router ID. OSPFv3 still uses a 32-bit, dotted-decimal RID and picks it from IPv4 addresses using the OSPFv2 rules (configured value, then highest up loopback IPv4, then highest up interface IPv4). An IPv6 address can never be the RID. On a router with both protocols and no router-id commands, OSPFv3 picks the same IPv4 loopback as OSPFv2.

IPv6-only routers need a configured router ID

If a router has no IPv4 address at all, OSPFv3 cannot choose a router ID: IOS logs that it could not pick one and asks for manual configuration, the process does not run, and no neighbors form. The fix is router-id under ipv6 router ospf, since only IPv4 addresses are ever candidates.

Link-local adjacencies

OSPFv3 sends its packets from the interface's link-local address (FE80::/10) to FF02::5 and FF02::6 (or unicast link-local). An interface with a global address already has a link-local one, so ipv6 enable is not needed there. Three consequences are tested:

• Next hops are link-local. Routes learned through OSPFv3 show via FE80::2, GigabitEthernet0/1, with the exit interface, rather than the neighbor's global address. That is normal OSPFv3 behaviour.
• No prefix check. OSPFv3 hellos carry no subnet mask, and adjacencies are per link, not per subnet, so two routers whose global addresses on the link are in different /64s (a typo, for example) still become FULL. In OSPFv2 a subnet mismatch would stop the adjacency.
• ACLs must allow link-local OSPF. An IPv6 ACL on the link must permit OSPF (next header 89) from FE80::/10 to FF02::5 for hellos, as well as to FF02::6 and to link-local unicast addresses. Because the source is link-local and the destination is an OSPF group, rules written only for the link's global addresses do not match OSPFv3 traffic.

What OSPFv3 advertises

An enabled interface advertises every global (and unique local) prefix configured on it; an interface with 2001:db8:a::1/64 and 2001:db8:b::1/64 advertises both /64s. Link-local addresses are never advertised. Verify with show ipv6 ospf neighbor, show ipv6 ospf interface brief and show ipv6 route ospf.