The following sections provide brief descriptions of key OSPF features supported in our implementation of OSPF.

Intra-area, Interarea, and External Routes

You can split up an OSPF AS into areas. Doing this reduces the size of the link-state database (LSDB). Each OSPF area runs as a separate network and maintains its own LSDB. OSPF computes routes only to destinations within the area, and does not flood routes beyond the area boundaries.

Routing Priority

OSPF areas receive routes based on priority. Table 52 describes the routing priority.

Table 52: Routing Priority




1 (highest)


Intra-area routing. Refers to routing within a single OSPF area.



Interarea routing. Refers to routing between OSPF areas within a single OSPF routing domain.



External type 1. Refers to routing from other protocols that can be imported into the OSPF domain and readvertised by OSPF as type 1 external.

Type 1 metric is comparable to the link-state metric; the cost is equal to the sum of the internal costs plus the external cost.

4 (lowest)


External type 2. Refers to routing from other protocols that can be imported into the OSPF domain and readvertised by OSPF as type 2 external.

Type 2 metric is much larger than the cost of any intra-AS path; the cost is equal to the external cost. This is the OSPF default.

If you use the redistribute command to import routes from other protocols or sources, the routes default to external type 2. You can specify a route map with the redistribute command to modify the type. Alternatively, you can use the metric-type keyword with the redistribute command to specify the type.

Virtual Links

Each OSPF area must be directly connected to the backbone area. The backbone is responsible for distributing routing information between nonbackbone areas. All routers in the backbone must be contiguous, but they need not be physically adjacent. You can configure backbone routers to be logically adjacent by creating OSPF virtual links.


OSPF supports three modes of authentication:

Opaque LSAs

OSPF opaque LSAs provide a generalized way of extending OSPF. The router generates opaque LSAs to carry traffic engineering information, accepts them from other routers, and floods them accordingly. OSPF uses the traffic engineering information to build a database from which paths can be computed for MPLS label-switched paths.

Route Leakage

Routes can be leaked into OSPF or from OSPF as follows:

Equal-Cost Multipath

OSPF inherently supports equal-cost multipath (ECMP). When building the shortest-path tree, OSPF calculates all paths of equal cost to a given destination. If equal-cost paths exist, OSPF inserts into the routing table the next hops for all equal-cost paths to a destination.


See the compressed software image bundle that you downloaded from the Juniper Networks website for complete information about the OSPF Management Information Base (MIB) supported by your router. The MIBs folder contains information about all supported standard and Juniper Networks E Series enterprise (proprietary) MIBs. OSPF does not act as a host within the router and therefore does not support the ospfIfMetric and ospfHost tables.

Interacting with Other Routing Protocols

OSPF interacts seamlessly with the following routing protocols:

Implementing OSPF for IPv6

OSPF version 3 (OSPFv3) specifies IPv6 support in the OSPF protocol. Compared with OSPF version 2, the fundamental mechanisms for OSPF remain unchanged. These mechanisms include the following:

Understanding the OSPFv3 Difference

OSPFv3 changes the way it describes the network topology. All addressing semantics have been removed from the LSA header and from router-LSAs and network-LSAs. These two LSAs now describe the topology of the routing domain in a network-protocol-independent manner (using interface identifiers and router identifiers). New LSAs have been added to distribute IPv6 address information and data required for next-hop resolution.

In addition to the obvious address and processing modifications to handle IPv6 addressing, changes in OSPFv3 include the following:

Supported LSA Types

OSPFv3 supports the following LSA types:

An LSA in OSPFv3 is still identified by its type, link-state ID, and the advertising router ID. However, the link-state ID (for all LSA types) no longer carries IP address information. Instead, the LSA carries either an arbitrarily assigned number or an interface ID.

The link-state ID always has a fixed length of 4 bytes. The LS type field is extended to 16 bits and encodes LSA flooding scope and specific actions to take when the router encounters unrecognized LS types.

An IPv6 address, if it is specified in an LSA, is represented by its prefix length, prefix options, and prefix address.

Note: If an OSPF interface receives a hello packet whose IP address is the same as the IP address of the neighbor interface, the hello packet is not processed and the OSPF neighbor adjacency is brought down.

Unsupported OSPF Components

This release does not support the following OSPF components when implementing OSPF for IPv6: