Features

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 11 describes the routing priority.

Table 11: Routing Priority

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.

Authentication

OSPF supports three modes of authentication:

• Null authentication—Implies that no authentication is in use.
• Simple password authentication—Requires a 64-bit unencrypted password in each OSPF packet.
• Cryptographic authentication—Uses a shared secret key that is configured on each router on a network. RFC 2328 defines the use of OSPF cryptographic authentication with the MD5 algorithm.

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:

• Route leakage into OSPF—When another routing protocol adds a new route to the routing table, or when a static route is added to the routing table, OSPF can be informed through the redistribute commands. When OSPF learns the new route, it floods the information into the routing domain by using external LSAs.
• Route leakage from OSPF—OSPF adds routing information to the routing table, which is used in forwarding IP packets.

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.

OSPF MIB

See the JUNOSe Software CD, shipped with your router, 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:

• IS-IS—OSPF was developed originally from an early version of the IS-IS intradomain routing protocol. OSPF can import IS-IS routing information. See Configuring IS-IS .
• RIP—E-series routers can simultaneously run OSPF and RIP. When doing so, OSPF routes are preferred over RIP. In general, use of the OSPF protocol is preferred because of its robustness, responsiveness, and decreased bandwidth requirements. See Configuring RIP .
• BGP—The default expectation is that your routing environment is an AS running OSPF and exchanging BGP routes with other ASs. See Configuring BGP Routing in the JUNOSe BGP and MPLS Configuration Guide.

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:

• OSPF designated router/border designated router election
• OSPF adjacency maintenance
• OSPF interface states, events, and interface state machine
• OSPF flooding mechanism
• OSPF LSA management
• SPF calculation

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:

• Authentication-related information is removed from the OSPF packet headers. Instead, OSPFv3 uses an authentication header in IPv6.
• OSPFv3 requires that each OSPF interface attached to a link be assigned a link-local unicast address.
• The option field for hello packets, database description (DD) packets, and LSAs has been expanded from 8 bits to 24 bits. In addition, two new LSA types have been added—link LSAs and intra-area prefix LSAs.
• The LSA flooding scope is more explicit in OSPFv3 and now appears in the LS type field. The LS type field also encodes a specific action to take for unknown LS types, allowing OSPF to function with unknown LS types instead of simply discarding them.
• The flooding process is modified to manage unrecognized LSAs and the new LSA flooding scope.
• The route calculation has been updated to handle modifications in the LSA database.

Supported LSA Types

OSPFv3 supports the following LSA types:

• Router LSA—Describes link state and costs of router links to the area; flooded within an area only
• Network LSA—Originated by the designated router for every broadcast or nonbroadcast multiaccess (NBMA) link having two or more attached routers; lists all routers attached to the link
• Interarea prefix LSA—Known as the type-3 summary LSA in OSPFv2; describes a prefix external to the area, yet internal to the AS
• Interarea router LSA—Called type 4 summary-LSAs in OSPFv2; describes a path to a destination OSPF router (that is, an AS boundary router) that is external to the area, yet internal to the AS
• AS-external LSA—Describes a path to a prefix external to the AS
• Link LSA (new for OSPFv3)—Provides the router’s link-local address to all other routers attached to the link; informs other routers attached to the link of a list of IPv6 prefixes to associate with the link; enables the router to assert a collection of options bits in the Network-LSA to be originated for the link
• Intra-area prefix LSA (new for OSPFv3)—Associates a list of IPv6 address prefixes with a transit network link by referencing a network LSA, or associates a list of IPv6 address prefixes with a router by referencing a router LSA

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.

Unsupported OSPF Components

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

• Virtual link
• Not-so-stubby-area (NSSA)
• Nonbroadcast multiaccess (NBMA)
• Remote neighbor
• Traffic engineering extensions
• SNMP traps
• Features specified in “OSPF as the PE/CE Protocol in BGP/MPLS IP VPNs” (draft-ietf-l3vpn-ospf-2547)

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.