Joining Two OSPF Networks
Strategies, Gotchas, and Best Practices for Safe Routing Integration
Connecting two OSPF networks may look simple: add a link, enable OSPF, and let routes exchange. In practice, merging OSPF domains without planning can create duplicate Router IDs, broken adjacencies, route loops, unexpected external routes, LSA flooding, and unstable convergence.
This article covers the technical issues commonly encountered when joining two OSPF networks and provides practical strategies for doing it safely in ISP, WISP, enterprise, municipal, and multi-vendor environments.
OSPF Is Not Just Route Exchange
OSPF is a link-state routing protocol. Routers do not simply exchange a list of routes; they exchange Link-State Advertisements, build a Link-State Database, and independently calculate the shortest path tree.
RFC 2328 defines OSPFv2 and states that each router maintains an identical database describing the area topology. That means a bad design decision in one part of the network can quickly affect every router participating in that OSPF area.
Common Reasons Two OSPF Networks Need to Be Joined
- ISP or WISP acquisition
- Municipal fiber network expansion
- Enterprise merger
- Data center interconnection
- Disaster recovery site integration
- Backbone redesign or hardware migration
- Migration from static routing or another IGP
The technical approach depends on whether the goal is a clean merge, temporary coexistence, staged migration, or long-term separation with controlled route leaking.
Gotcha #1: Duplicate Router IDs
Every OSPF router must have a unique Router ID. The Router ID is not merely cosmetic; it identifies the router in the OSPF Link-State Database.
Network A Router ID: 10.255.255.1
Network B Router ID: 10.255.255.1Duplicate Router IDs can cause LSA conflicts, adjacency instability, SPF recalculations, and routes disappearing or changing unexpectedly. Always audit Router IDs before joining OSPF domains.
Gotcha #2: Overlapping IP Space
OSPF cannot solve overlapping addressing. If both networks use the same internal prefixes, the routing protocol has no way to know which identical prefix should be preferred unless you isolate or redesign the topology.
Network A: 10.0.0.0/16
Network B: 10.0.0.0/16Options include renumbering, VRFs, NAT during migration, route filtering, or staged route leaking. Do not simply connect the two domains and hope OSPF will sort it out.
Gotcha #3: Area 0 and Backbone Design
In OSPF, Area 0 is the backbone area. Non-backbone areas are expected to connect to Area 0 through Area Border Routers. When two networks are joined, it is common to discover disconnected backbones, multiple Area 0 islands, or virtual links being used as permanent design shortcuts.
A merger is often the right time to redesign the OSPF area hierarchy, summarize routes at ABRs, and reduce unnecessary LSA flooding.
Gotcha #4: MTU Mismatches
OSPF neighbors can become stuck in EXSTART or EXCHANGE when interface MTUs do not match. This commonly happens when joining fiber backbones, GRE/VXLAN transport, MPLS circuits, or mixed vendor networks.
Router A MTU: 1500
Router B MTU: 9000
Possible symptom:
Neighbor state: EXSTART / EXCHANGEBefore troubleshooting authentication or firewalls, verify MTU, encapsulation overhead, and whether the transport path supports the configured packet size end-to-end.
Gotcha #5: Authentication and Timers
OSPF neighbors must agree on several parameters before adjacency can form correctly. Authentication, hello interval, dead interval, network type, area ID, and stub flags all matter.
- Area ID must match
- Hello and dead timers must match
- Authentication must match
- Stub/NSSA flags must match
- Network type must be compatible
- MTU should match or be intentionally handled
RFC 5709 defines HMAC-SHA authentication for OSPFv2 and is preferred over older simple password methods.
Strategy 1: Clean OSPF Merge
A clean merge is appropriate when both networks have unique Router IDs, non-overlapping addressing, compatible area design, and a shared operational standard.
This is the simplest design, but it should only be used after a full audit. Once the adjacency forms, LSAs can flood rapidly, and every router in the affected areas may recalculate SPF.
Strategy 2: Temporary Redistribution
Redistribution can be used when two OSPF domains need to communicate but should not yet share a single LSDB. This is common during acquisitions or staged migrations.
OSPF Domain A
|
Redistribution Boundary
|
OSPF Domain BRedistribution requires route tagging, filtering, summarization, and loop prevention. It should generally be treated as a migration tool, not a permanent substitute for proper design.
Strategy 3: VRF-Based Integration
VRFs are often the safest way to join networks with overlapping IP space, different security zones, or unclear routing policies. Each network remains isolated while selected routes are leaked under controlled policy.
VRF-based migration allows the operator to renumber gradually, test reachability, and prevent accidental full-table exposure between networks.
Strategy 4: Backbone Redesign
Sometimes the best strategy is not to join two existing OSPF designs exactly as they are. If both networks grew organically over years, a merger may expose poor summarization, too many areas, weak authentication, inconsistent timers, and unclear ABR placement.
A redesigned backbone can reduce LSDB size, improve convergence, simplify troubleshooting, and make the network easier to operate long-term.
Pre-Migration Checklist
- Inventory all OSPF routers and Router IDs
- Audit IP addressing for overlap
- Document all areas, ABRs, ASBRs, and redistribution points
- Review summarization and route filters
- Verify MTU across interconnects and tunnels
- Verify authentication method and key rollover process
- Validate hello/dead timers and network types
- Check for stub, totally stubby, and NSSA area differences
- Model expected route changes before enabling adjacency
- Prepare rollback procedures before the maintenance window
The goal is to avoid discovering design problems only after both OSPF domains are already exchanging LSAs.
How Link Technologies Inc. Can Help
Joining two OSPF networks is not just a routing change; it is a network architecture project. Link Technologies Inc. provides ISP-grade and enterprise-grade consulting for routing design, MikroTik, Cisco, Juniper, BGP, OSPF, VRF, failover, documentation, and operational planning.
- OSPF design and migration planning
- Multi-vendor routing reviews
- ISP and WISP acquisition network due diligence
- RouterOS, Cisco, Juniper, and multi-vendor troubleshooting
- VRF, route leaking, summarization, and failover design
- Network documentation, diagrams, IP plans, and change records
Learn more about our consulting services here:
https://shop.linktechs.net/what-we-do
Leave your comment