Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Introduction to OSPF

 

OSPF Overview

OSPF is an interior gateway protocol (IGP) that routes packets within a single autonomous system (AS). OSPF uses link-state information to make routing decisions, making route calculations using the shortest-path-first (SPF) algorithm (also referred to as the Dijkstra algorithm). Each router running OSPF floods link-state advertisements throughout the AS or area that contain information about that router’s attached interfaces and routing metrics. Each router uses the information in these link-state advertisements to calculate the least cost path to each network and create a routing table for the protocol.

Junos OS supports OSPF version 2 (OSPFv2) and OSPF version 3 (OSPFv3), including virtual links, stub areas, and for OSPFv2, authentication. Junos OS does not support type-of-service (ToS) routing.

OSPF was designed for the Transmission Control Protocol/Internet Protocol (TCP/IP) environment and as a result explicitly supports IP subnetting and the tagging of externally derived routing information. OSPF also provides for the authentication of routing updates.

OSPF routes IP packets based solely on the destination IP address contained in the IP packet header. OSPF quickly detects topological changes, such as when router interfaces become unavailable, and calculates new loop-free routes quickly and with a minimum of routing overhead traffic.

Note

On SRX Series devices, when only one link-protection is configured under the OSPF interface, the device does not install an alternative route in the forwarding table. When the per-packet load-balancing is enabled as a workaround, the device does not observe both the OSPF metric and sending the traffic through both the interfaces.

An OSPF AS can consist of a single area, or it can be subdivided into multiple areas. In a single-area OSPF network topology, each router maintains a database that describes the topology of the AS. Link-state information for each router is flooded throughout the AS. In a multiarea OSPF topology, each router maintains a database that describes the topology of its area, and link-state information for each router is flooded throughout that area. All routers maintain summarized topologies of other areas within an AS. Within each area, OSPF routers have identical topological databases. When the AS or area topology changes, OSPF ensures that the contents of all routers’ topological databases converge quickly.

All OSPFv2 protocol exchanges can be authenticated. OSPFv3 relies on IPsec to provide this functionality. This means that only trusted routers can participate in the AS’s routing. A variety of authentication schemes can be used. A single authentication scheme is configured for each area, which enables some areas to use stricter authentication than others.

Externally derived routing data (for example, routes learned from BGP) is passed transparently throughout the AS. This externally derived data is kept separate from the OSPF link-state data. Each external route can be tagged by the advertising router, enabling the passing of additional information between routers on the boundaries of the AS.

Note

By default, Junos OS is compatible with RFC 1583, OSPF Version 2. In Junos OS Release 8.5 and later, you can disable compatibility with RFC 1583 by including the no-rfc-1583 statement. For more information, see Example: Disabling OSPFv2 Compatibility with RFC 1583.

This topic describes the following information:

OSPF Default Route Preference Values

The Junos OS routing protocol process assigns a default preference value to each route that the routing table receives. The default value depends on the source of the route. The preference value is from 0 through 4,294,967,295 (232 – 1), with a lower value indicating a more preferred route. Table 1 lists the default preference values for OSPF.

Table 1: Default Route Preference Values for OSPF

How Route Is Learned

Default Preference

Statement to Modify Default Preference

OSPF internal route

10

OSPF preference

OSPF AS external routes

150

OSPF external-preference

OSPF Routing Algorithm

OSPF uses the shortest-path-first (SPF) algorithm, also referred to as the Dijkstra algorithm, to determine the route to each destination. All routing devices in an area run this algorithm in parallel, storing the results in their individual topological databases. Routing devices with interfaces to multiple areas run multiple copies of the algorithm. This section provides a brief summary of how the SPF algorithm works.

When a routing device starts, it initializes OSPF and waits for indications from lower-level protocols that the router interfaces are functional. The routing device then uses the OSPF hello protocol to acquire neighbors, by sending hello packets to its neighbors and receiving their hello packets.

On broadcast or nonbroadcast multiaccess networks (physical networks that support the attachment of more than two routing devices), the OSPF hello protocol elects a designated router for the network. This routing device is responsible for sending link-state advertisements (LSAs) that describe the network, which reduces the amount of network traffic and the size of the routing devices’ topological databases.

The routing device then attempts to form adjacencies with some of its newly acquired neighbors. (On multiaccess networks, only the designated router and backup designated router form adjacencies with other routing devices.) Adjacencies determine the distribution of routing protocol packets. Routing protocol packets are sent and received only on adjacencies, and topological database updates are sent only along adjacencies. When adjacencies have been established, pairs of adjacent routers synchronize their topological databases.

A routing device sends LSA packets to advertise its state periodically and when its state changes. These packets include information about the routing device’s adjacencies, which allows detection of nonoperational routing devices.

Using a reliable algorithm, the routing device floods LSAs throughout the area, which ensures that all routing devices in an area have exactly the same topological database. Each routing device uses the information in its topological database to calculate a shortest-path tree, with itself as the root. The routing device then uses this tree to route network traffic.

The description of the SPF algorithm up to this point has explained how the algorithm works within a single area (intra-area routing). For internal routers to be able to route to destinations outside the area (interarea routing), the area border routers must inject additional routing information into the area. Because the area border routers are connected to the backbone, they have access to complete topological data about the backbone. The area border routers use this information to calculate paths to all destinations outside its area and then advertise these paths to the area’s internal routers.

Autonomous system (AS) boundary routers flood information about external autonomous systems throughout the AS, except to stub areas. Area border routers are responsible for advertising the paths to all AS boundary routers.

OSPF Three-Way Handshake

OSPF creates a topology map by flooding LSAs across OSPF-enabled links. LSAs announce the presence of OSPF-enabled interfaces to adjacent OSPF interfaces. The exchange of LSAs establishes bidirectional connectivity between all adjacent OSPF interfaces (neighbors) using a three-way handshake, as shown in Figure 1.

Figure 1: OSPF Three-Way Handshake
OSPF Three-Way Handshake

In Figure 1, Router A sends hello packets out all its OSPF-enabled interfaces when it comes online. Router B receives the packet, which establishes that Router B can receive traffic from Router A. Router B generates a response to Router A to acknowledge receipt of the hello packet. When Router A receives the response, it establishes that Router B can receive traffic from Router A. Router A then generates a final response packet to inform Router B that Router A can receive traffic from Router B. This three-way handshake ensures bidirectional connectivity.

As new neighbors are added to the network or existing neighbors lose connectivity, the adjacencies in the topology map are modified accordingly through the exchange (or absence) of LSAs. These LSAs advertise only the incremental changes in the network, which helps minimize the amount of OSPF traffic on the network. The adjacencies are shared and used to create the network topology in the topological database.

OSPF Version 3

OSPFv3 is a modified version of OSPF that supports IP version 6 (IPv6) addressing. OSPFv3 differs from OSPFv2 in the following ways:

  • All neighbor ID information is based on a 32-bit router ID.

  • The protocol runs per link rather than per subnet.

  • Router and network link-state advertisements (LSAs) do not carry prefix information.

  • Two new LSA types are included: link-LSA and intra-area-prefix-LSA.

  • Flooding scopes are as follows:

    • Link-local

    • Area

    • AS

  • Link-local addresses are used for all neighbor exchanges except virtual links.

  • Authentication is removed. The IPv6 authentication header relies on the IP layer.

  • The packet format has changed as follows:

    • Version number 2 is now version number 3.

    • The db option field has been expanded to 24 bits.

    • Authentication information has been removed.

    • Hello messages do not have address information.

    • Two new option bits are included: R and V6.

  • Type 3 summary LSAs have been renamed inter-area-prefix-LSAs.

  • Type 4 summary LSAs have been renamed inter-area-router-LSAs.

OSPF Packets Overview

There are several types of link-state advertisement (LSA) packets.

This topic describes the following information:

OSPF Packet Header

All OSPFv2 packets have a common 24-byte header, and OSPFv3 packets have a common 16-byte header, that contains all information necessary to determine whether OSPF should accept the packet. The header consists of the following fields:

  • Version number—The current OSPF version number. This can be either 2 or 3.

  • Type—Type of OSPF packet.

  • Packet length—Length of the packet, in bytes, including the header.

  • Router ID—IP address of the router from which the packet originated.

  • Area ID—Identifier of the area in which the packet is traveling. Each OSPF packet is associated with a single area. Packets traveling over a virtual link are labeled with the backbone area ID, 0.0.0.0. .

  • Checksum—Fletcher checksum.

  • Authentication—(OSPFv2 only) Authentication scheme and authentication information.

  • Instance ID—(OSPFv3 only) Identifier used when there are multiple OSPFv3 realms configured on a link.

Hello Packets

Routers periodically send hello packets on all interfaces, including virtual links, to establish and maintain neighbor relationships. Hello packets are multicast on physical networks that have a multicast or broadcast capability, which enables dynamic discovery of neighboring routers. (On nonbroadcast networks, dynamic neighbor discovery is not possible, so you must configure all neighbors statically as described in Example: Configuring an OSPFv2 Interface on a Nonbroadcast Multiaccess Network.)

Hello packets consist of the OSPF header plus the following fields:

  • Network mask—(OSPFv2 only) Network mask associated with the interface.

  • Hello interval—How often the router sends hello packets. All routers on a shared network must use the same hello interval.

  • Options—Optional capabilities of the router.

  • Router priority—The router’s priority to become the designated router.

  • Router dead interval—How long the router waits without receiving any OSPF packets from a router before declaring that router to be down. All routers on a shared network must use the same router dead interval.

  • Designated router—IP address of the designated router.

  • Backup designated router—IP address of the backup designated router.

  • Neighbor—IP addresses of the routers from which valid hello packets have been received within the time specified by the router dead interval.

Database Description Packets

When initializing an adjacency, OSPF exchanges database description packets, which describe the contents of the topological database. These packets consist of the OSPF header, packet sequence number, and the link-state advertisement’s header.

Link-State Request Packets

When a router detects that portions of its topological database are out of date, it sends a link-state request packet to a neighbor requesting a precise instance of the database. These packets consist of the OSPF header plus fields that uniquely identify the database information that the router is seeking.

Link-State Update Packets

Link-state update packets carry one or more link-state advertisements one hop farther from their origin. The router multicasts (floods) these packets on physical networks that support multicast or broadcast mode. The router acknowledges all link-state update packets and, if retransmission is necessary, sends the retransmitted advertisements unicast.

Link-state update packets consist of the OSPF header plus the following fields:

  • Number of advertisements—Number of link-state advertisements included in this packet.

  • Link-state advertisements—The link-state advertisements themselves.

Link-State Acknowledgment Packets

The router sends link-state acknowledgment packets in response to link-state update packets to verify that the update packets have been received successfully. A single acknowledgment packet can include responses to multiple update packets.

Link-state acknowledgment packets consist of the OSPF header plus the link-state advertisement header.

Link-State Advertisement Packet Types

Link-state request, link-state update, and link-state acknowledgment packets are used to reliably flood link-state advertisement packets. OSPF sends the following types of link-state advertisements:

  • Router link advertisements—Are sent by all routers to describe the state and cost of the router’s links to the area. These link-state advertisements are flooded throughout a single area only.

  • Network link advertisements—Are sent by designated routers to describe all the routers attached to the network. These link-state advertisements are flooded throughout a single area only.

  • Summary link advertisements—Are sent by area border routers to describe the routes that they know about in other areas. There are two types of summary link advertisements: those used when the destination is an IP network, and those used when the destination is an AS boundary router. Summary link advertisements describe interarea routes, that is, routes to destinations outside the area but within the AS. These link-state advertisements are flooded throughout the advertisement’s associated areas.

  • AS external link advertisement—Are sent by AS boundary routers to describe external routes that they know about. These link-state advertisements are flooded throughout the AS (except for stub areas).

Each link-state advertisement type describes a portion of the OSPF routing domain. All link-state advertisements are flooded throughout the AS.

Each link-state advertisement packet begins with a common 20-byte header.

Understanding OSPF External Metrics

When OSPF exports route information from external autonomous systems (ASs), it includes a cost, or external metric, in the route. OSPF supports two types of external metrics: Type 1 and Type 2. The difference between the two metrics is how OSPF calculates the cost of the route.

  • Type 1 external metrics are equivalent to the link-state metric, where the cost is equal to the sum of the internal costs plus the external cost. This means that Type 1 external metrics include the external cost to the destination as well as the cost (metric) to reach the AS boundary router.

  • Type 2 external metrics are greater than the cost of any path internal to the AS. Type 2 external metrics use only the external cost to the destination and ignore the cost (metric) to reach the AS boundary router.

By default, OSPF uses the Type 2 external metric.

Both Type 1 and Type 2 external metrics can be present in the AS at the same time. In that event, Type 1 external metrics always takes the precedence.

Type 1 external paths are always preferred over Type 2 external paths. When all paths are Type 2 external paths, the paths with the smallest advertised Type 2 metric are always preferred.

Supported OSPF and OSPFv3 Standards

Junos OS substantially supports the following RFCs and Internet drafts, which define standards for OSPF and OSPF version 3 (OSPFv3).

  • RFC 1583, OSPF Version 2

  • RFC 1765, OSPF Database Overflow

  • RFC 1793, Extending OSPF to Support Demand Circuits

  • RFC 1850, OSPF Version 2 Management Information Base

  • RFC 2154, OSPF with Digital Signatures

  • RFC 2328, OSPF Version 2

  • RFC 2370, The OSPF Opaque LSA Option

    Support is provided by the update-threshold configuration statement at the [edit protocols rsvp interface interface-name ] hierarchy level.

  • RFC 3101, The OSPF Not-So-Stubby Area (NSSA) Option

  • RFC 3623, Graceful OSPF Restart

  • RFC 3630, Traffic Engineering (TE) Extensions to OSPF Version 2

  • RFC 4136, OSPF Refresh and Flooding Reduction in Stable Topologies

  • RFC 4203, OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)

    Only interface switching is supported.

  • RFC 4552, Authentication/Confidentiality for OSPFv3

  • RFC 4576, Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 4577, OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)

  • RFC 4811, OSPF Out-of-Band Link State Database (LSDB) Resynchronization

  • RFC 4812, OSPF Restart Signaling

  • RFC 4813, OSPF Link-Local Signaling

  • RFC 4915, Multi-Topology (MT) Routing in OSPF

  • RFC 5185, OSPF Multi-Area Adjacency

  • RFC 5187, OSPFv3 Graceful Restart

  • RFC 5250, The OSPF Opaque LSA Option

    Note

    RFC 4750, mentioned in this RFC as a "should" requirement is not supported. However, RFC 1850, the predecessor to RFC 4750 is supported.

  • RFC 5286, Basic Specification for IP Fast Reroute: Loop-Free Alternates

  • RFC 5340, OSPF for IPv6 (RFC 2740 is obsoleted by RFC 5340)

  • RFC 5838, Support of Address Families in OSPFv3

  • Internet draft draft-ietf-ospf-af-alt-10.txt, Support of address families in OSPFv3

  • Internet draft draft-katz-ward-bfd-02.txt, Bidirectional Forwarding Detection

    Transmission of echo packets is not supported.

The following RFCs do not define standards, but provide information about OSPF and related technologies. The IETF classifies them as “Informational.”

  • RFC 3137, OSPF Stub Router Advertisement

  • RFC 3509, Alternative Implementations of OSPF Area Border Routers

  • RFC 5309, Point-to-Point Operation over LAN in Link State Routing Protocols