8.3 OSPFv2 & OSPFv3 Configuration and Verification

OSPFv2 & OSPFv3 Configuration and Verification

Implementing OSPF on Juniper EX Series switches, MX Series routers, and SRX Series security gateways requires configuring interface parameters under the [edit protocols ospf] hierarchy for IPv4 and [edit protocols ospf3] for IPv6. In addition to basic protocol activation, enterprise deployments require tuning interface types, configuring passive subnets, adjusting reference bandwidth metrics, and conducting systematic verification.

---

1. Junos OSPFv2 Configuration Hierarchy

In Junos OS, OSPF is not enabled by applying network wildcard masks as seen in some traditional network operating systems. Instead, interfaces are explicitly assigned to specific OSPF areas under [edit protocols ospf area <area-id>]:

[edit]
user@EX4300# edit protocols ospf

[edit protocols ospf]
user@EX4300# set area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p
user@EX4300# set area 0.0.0.0 interface ge-0/0/1.0 priority 200
user@EX4300# set area 0.0.0.0 interface lo0.0 passive

In this configuration:

• area 0.0.0.0: Specifies the backbone area. Junos accepts both dotted-decimal (0.0.0.0) and integer (0) formats interchangeably.
• interface-type p2p: Overrides the default broadcast mode on Ethernet interface ge-0/0/0.0. On point-to-point router links, this eliminates DR/BDR election overhead and speeds up convergence.
• priority 200: Raises the DR election priority on ge-0/0/1.0 above the Junos default of 128 to influence Designated Router election.
• passive: Declares lo0.0 as a passive interface.

---

2. Passive Interface Mechanics & Security

In enterprise networks, access switch VLANs (such as user, VoIP, or printer subnets terminating on irb interfaces) must be advertised across the OSPF backbone so that endpoints can be reached. However, running active OSPF on user-facing ports creates serious security and efficiency vulnerabilities:

• Untrusted client machines or unauthorized switches could send OSPF Hellos, form adjacencies, and inject rogue routes into the enterprise core.
• Continuous transmission of OSPF Hello multicasts consumes unnecessary bandwidth on client access ports.

+---------------------------------------------------------------------------------------------------+
| PASSIVE INTERFACE OPERATION                                                                       |
|                                                                                                   |
|  Active OSPF Interface (ge-0/0/0.0):                                                              |
|    [Router] <======== Hello / DBD / LSR / LSU / LSAck ========> [Neighbor Router]                 |
|    - Transmits and receives OSPF packets; forms full adjacency.                                   |
|                                                                                                   |
|  Passive Interface (irb.10):                                                                      |
|    [Router] --x (Suppressed Hellos) --x [User PC / Workstation]                                   |
|    - Subnet 10.1.10.0/24 is included in Type 1 Router LSA as a Stub Network.                      |
|    - No Hellos transmitted or accepted; no neighbor adjacency can ever form.                      |
+---------------------------------------------------------------------------------------------------+

Applying the passive statement under an interface stanza instructs Junos to:

1. Advertise the interface's IP subnet as a Stub Network link inside the local Type 1 Router LSA.
2. Completely suppress the generation of OSPF Hello packets out of that interface.
3. Discard any incoming OSPF packets arriving on that interface, ensuring no neighbor adjacency can ever form.

[edit protocols ospf area 0.0.0.0]
user@EX4300# set interface irb.10 passive
user@EX4300# set interface irb.20 passive

---

3. Metric Calculation & Reference Bandwidth Tuning

OSPF determines the cost of an interface using a metric calculation inversely proportional to the interface bandwidth:

$\text{Cost} = \frac{\text{Reference Bandwidth}}{\text{Interface Bandwidth}}$

By default, Junos OS defines the reference bandwidth as 100 Mbps ($10^8$ bps). Because the minimum OSPF link cost is an integer value of 1, any interface with a bandwidth equal to or greater than 100 Mbps receives a cost of 1:

+---------------------------------------------------------------------------------------------------+
| DEFAULT VS ADJUSTED REFERENCE BANDWIDTH METRIC COMPARISON                                         |
+----------------------+--------------------+-----------------------+-------------------------------+
| Interface Speed      | Nominal Bandwidth  | Default Cost (100M)   | Adjusted Cost (100G Ref-BW)   |
+----------------------+--------------------+-----------------------+-------------------------------+
| Fast Ethernet        | 100 Mbps           | 1                     | 1,000                         |
| Gigabit Ethernet     | 1 Gbps (1,000M)    | 1 (100M/1G = 0.1 -> 1)| 100                           |
| 10-Gigabit Ethernet  | 10 Gbps (10,000M)  | 1 (100M/10G = 0.01->1)| 10                            |
| 100-Gigabit Ethernet | 100 Gbps           | 1 (100M/100G = 0.001) | 1                             |
+----------------------+--------------------+-----------------------+-------------------------------+

The Metric Differentiation Problem

Under the default 100 Mbps reference bandwidth, a 100 Mbps FastEthernet uplink, a 1 Gbps trunk, a 10 Gbps core link, and a 100 Gbps backbone link all share the exact same metric of 1. OSPF cannot differentiate link speeds, potentially routing high-volume core traffic over a saturated 1 Gbps link instead of an available 10 Gbps path.

To restore correct path calculation, enterprise administrators must explicitly set a modern reference bandwidth at the top level of the OSPF hierarchy:

[edit protocols ospf]
user@EX4300# set reference-bandwidth 100g

Critical Requirement: The reference-bandwidth must be configured identically on every router in the entire OSPF domain. If routers compute costs using different reference bandwidths, path metrics become asymmetric, producing asymmetric or unintended path costs. Matching reference bandwidth is an operational consistency practice, not an adjacency requirement.

---

4. OSPFv3 Architecture for IPv6

OSPFv3 (RFC 5340) adapts the link-state mechanics of OSPF to support IPv6. While the core algorithms (Dijkstra SPF) and state machines remain identical, OSPFv3 introduces significant architectural shifts:

1. Runs Per-Link Rather Than Per-Subnet: In OSPFv2, neighbors must reside on the same IPv4 subnet to form an adjacency. In OSPFv3, neighbors form adjacencies across a physical link using their IPv6 Link-Local addresses (fe80::/10), regardless of whether they share common global unicast prefixes.
2. Decoupling of Addresses from Topology: OSPFv2 Type 1 and Type 2 LSAs carry both topological connection graphs and IPv4 prefix information. OSPFv3 removes IP prefix data from Type 1 and Type 2 LSAs entirely, using them purely to map node connectivity. Two new LSA types carry prefix reachability:
   • Type 8: Link LSA: Flooded link-local only. Advertises the router's link-local address and any IPv6 global unicast prefixes configured on that link.
   • Type 9: Intra-Area Prefix LSA: Flooded intra-area. Carries all IPv6 prefixes associated with a router (referencing a Type 1 LSA) or associated with a transit multi-access network (referencing a Type 2 LSA).
3. 32-Bit Router ID: Even in a pure IPv6 environment, OSPFv3 routers still identify themselves using a 32-bit Router ID represented in IPv4 dotted-decimal syntax (e.g., 10.255.0.1).

Junos OSPFv3 Configuration

OSPFv3 is configured under the distinct [edit protocols ospf3] hierarchy:

[edit]
user@EX4300# edit protocols ospf3

[edit protocols ospf3]
user@EX4300# set area 0.0.0.0 interface ge-0/0/0.0
user@EX4300# set area 0.0.0.0 interface lo0.0 passive

OSPFv2 and OSPFv3 operate as separate, independent routing protocol processes inside Junos (rpd), maintaining isolated neighbor sessions and separate link-state databases.

---

5. Operational Verification Commands

Junos provides comprehensive operational commands to verify and troubleshoot OSPF operations:

show ospf neighbor

Displays the status of immediate OSPF adjacencies:

user@EX4300> show ospf neighbor
Address          Interface              State     ID               Pri  Dead
192.168.12.2     ge-0/0/0.0             Full      10.255.0.2       128    36
192.168.14.2     ge-0/0/1.0             2Way      10.255.0.3       128    32

• State: Confirms whether the neighbor has reached Full (synchronized) or 2Way (DROther neighbor on broadcast network).
• Dead: Countdown timer (default 40s) reset each time a valid Hello is received.

show ospf interface

Verifies interface settings, cost, and DR/BDR roles:

user@EX4300> show ospf interface ge-0/0/0.0
Interface           State   Area            DR ID           BDR ID          Nbrs
ge-0/0/0.0          DR      0.0.0.0         10.255.0.1      10.255.0.2         1
  Type: LAN, Address: 192.168.12.1, Mask: 255.255.255.0, MTU: 1500, Cost: 100
  Adj count: 1, Priority: 128, Hello: 10, Dead: 40

show route protocol ospf

Verifies that OSPF has installed computed shortest-path routes into the master routing table (inet.0), displaying route preference (default 10 for internal routes) and metric.

Output note: Command output shown here is a schematic teaching example, not a captured device session. Field names and feature support depend on platform and Junos release.

OSPFv3 Realms and Address Families

A realm selects an OSPFv3 address family. IPv6 unicast is the default realm. Other supported realms are ipv4-unicast, ipv4-multicast, and ipv6-multicast; they separate the routing information calculated and advertised. A realm is not an OSPF area or a tenant routing instance. Each realm still has its own area/interface configuration and database context.

For example, on supported platforms, IPv4 unicast over OSPFv3 is configured under protocols ospf3 realm ipv4-unicast area 0.0.0.0 interface ge-0/0/0.0. Both endpoints must support and configure the same realm. Enabling only ordinary protocols ospf3 area ... configures default IPv6 unicast, not an IPv4 realm. OSPFv3 still uses IPv6 link-local transport, so working IPv4 addressing alone is insufficient to establish its neighbor exchange.

When a neighbor appears healthy but the intended family’s routes are missing, inspect the realm explicitly: show ospf3 route realm ipv4-unicast and show ospf3 log realm ipv4-unicast. Compare the protocol database with show route table inet.0 for IPv4 and inet6.0 for IPv6. A route in one family’s protocol view does not prove it was installed in the other family’s RIB. This separation helps diagnose the difference between an adjacency problem, a wrong realm, and a competing active route.

Official references checked 2026-10-18: OSPFv3 realms.