Single-Area OSPFv2 Configuration

Enabling OSPF is a two-decision job: pick a process, then tell it which interfaces participate. The process is created with router ospf <process-id>. The process ID is locally significant (Week's earlier lesson) — pick any number; it need not match neighbors. The second decision — which interfaces — has two valid styles.

Style 1 — the network statement (classic). Inside the process you list networks with a wildcard mask and an area:

R1(config)# router ospf 1
R1(config-router)# network 10.1.1.0 0.0.0.255 area 0
R1(config-router)# network 10.1.12.0 0.0.0.3 area 0

The statement does not advertise a subnet directly. It is a match rule: OSPF looks at every local interface, and any interface whose IP falls within address/wildcard is enabled for OSPF in the stated area. So network 10.1.1.0 0.0.0.255 area 0 enables OSPF on whatever local interface sits in 10.1.1.0/24. The wildcard is the inverse of the subnet mask: /24 → 0.0.0.255, /30 → 0.0.0.3, a single host /32 → 0.0.0.0.

Style 2 — interface-level (modern, explicit). Instead of matching, you enable OSPF directly on the interface:

R1(config)# interface GigabitEthernet0/1
R1(config-if)# ip ospf 1 area 0

This is unambiguous — you can see OSPF is on this interface without reverse-engineering a wildcard — and it is common in labs. Prefer it when you want zero ambiguity about which interfaces run OSPF; prefer network statements when a single line can cleanly cover a range of interfaces. Both coexist. Either way, area 0 is the backbone, and every router in a single-area design lives in it.

Network-statement vs interface enablement and wildcard rules (topic guide)

Pin the Router ID. OSPF chooses its RID at process start: manual router-id first, else the highest loopback IP, else the highest active physical IP. Letting it default means an interface flap or a new loopback can silently change the router's identity — and duplicate RIDs across routers cause real faults. Set it explicitly:

R1(config)# router ospf 1
R1(config-router)# router-id 1.1.1.1

A RID change after the process is running does not take effect until you run clear ip ospf process (or reload). Forgetting that step is a common "I set it but it did not change" moment.

Passive interfaces advertise without adjacency. On a LAN facing end hosts there is no OSPF neighbor to talk to, yet sending Hellos out that interface wastes CPU and — worse — invites a rogue router to peer with you. passive-interface stops Hellos on an interface while still advertising that connected network into OSPF:

R1(config-router)# passive-interface GigabitEthernet0/0

The subtle, exam-relevant point: passive-interface does not remove the route. The 10.1.1.0/24 LAN is still flooded to the rest of the area — you simply stop forming adjacencies out that port. Apply it to user LANs; never apply it to a transit link, or you kill the adjacency you need. You can also flip the default with passive-interface default and then selectively no passive-interface the transit links.

Passive-interface behavior and use cases (topic guide)