RFC 1583
OSPF Version 2
C. Configurable Constants The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters. Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters, and all routers attached to a network must agree on that network's IP network number and mask. Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable. C.1 Global parameters In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below. Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. One algorithm for Router ID assignment is to choose the largest or smallest IP address assigned to the router. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting in order to change its Router ID, the router should flush its self-originated link state advertisements from the routing domain (see Section 14.1), or they will persist for up to MaxAge minutes. TOS capability This item indicates whether the router will calculate separate routes based on TOS. For more information, see Sections 4.5 and 16.9. C.2 Area parameters All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of routing protocol and data
traffic. The following items must be configured for an area:
Area ID
This is a 32-bit number that identifies the area. The Area
ID of 0.0.0.0 is reserved for the backbone. If the area
represents a subnetted network, the IP network number of the
subnetted network may be used for the Area ID.
List of address ranges
An OSPF area is defined as a list of address ranges. Each
address range consists of the following items:
[IP address, mask]
Describes the collection of IP addresses contained
in the address range. Networks and hosts are
assigned to an area depending on whether their
addresses fall into one of the area's defining
address ranges. Routers are viewed as belonging to
multiple areas, depending on their attached
networks' area membership.
Status Set to either Advertise or DoNotAdvertise. Routing
information is condensed at area boundaries.
External to the area, at most a single route is
advertised (via a summary link advertisement) for
each address range. The route is advertised if and
only if the address range's Status is set to
Advertise. Unadvertised ranges allow the existence
of certain networks to be intentionally hidden from
other areas. Status is set to Advertise by default.
As an example, suppose an IP subnetted network is to be its
own OSPF area. The area would be configured as a single
address range, whose IP address is the address of the
subnetted network, and whose mask is the natural class A, B,
or C address mask. A single route would be advertised
external to the area, describing the entire subnetted
network.
AuType
Each area can be configured for a separate type of
authentication. See Appendix D for a discussion of the
defined authentication types.
ExternalRoutingCapability
Whether AS external advertisements will be flooded
into/throughout the area. If AS external advertisements are
excluded from the area, the area is called a "stub".
Internal to stub areas, routing to external destinations
will be based solely on a default summary route. The
backbone cannot be configured as a stub area. Also, virtual
links cannot be configured through stub areas. For more
information, see Section 3.6.
StubDefaultCost
If the area has been configured as a stub area, and the
router itself is an area border router, then the
StubDefaultCost indicates the cost of the default summary
link that the router should advertise into the area. There
can be a separate cost configured for each IP TOS. See
Section 12.4.3 for more information.
C.3 Router interface parameters
Some of the configurable router interface parameters (such as IP
interface address and subnet mask) actually imply properties of
the attached networks, and therefore must be consistent across
all the routers attached to that network. The parameters that
must be configured for a router interface are:
IP interface address
The IP protocol address for this interface. This uniquely
identifies the router over the entire internet. An IP
address is not required on serial lines. Such a serial line
is called "unnumbered".
IP interface mask
Also referred to as the subnet mask, this indicates the
portion of the IP interface address that identifies the
attached network. Masking the IP interface address with the
IP interface mask yields the IP network number of the
attached network. On point-to-point networks and virtual
links, the IP interface mask is not defined. On these
networks, the link itself is not assigned an IP network
number, and so the addresses of each side of the link are
assigned independently, if they are assigned at all.
Interface output cost(s)
The cost of sending a packet on the interface, expressed in
the link state metric. This is advertised as the link cost
for this interface in the router's router links
advertisement. There may be a separate cost for each IP
Type of Service. The interface output cost(s) must always
be greater than 0.
RxmtInterval
The number of seconds between link state advertisement
retransmissions, for adjacencies belonging to this
interface. Also used when retransmitting Database
Description and Link State Request Packets. This should be
well over the expected round-trip delay between any two
routers on the attached network. The setting of this value
should be conservative or needless retransmissions will
result. It will need to be larger on low speed serial lines
and virtual links. Sample value for a local area network: 5
seconds.
InfTransDelay
The estimated number of seconds it takes to transmit a Link
State Update Packet over this interface. Link state
advertisements contained in the update packet must have
their age incremented by this amount before transmission.
This value should take into account the transmission and
propagation delays of the interface. It must be greater
than 0. Sample value for a local area network: 1 second.
Router Priority
An 8-bit unsigned integer. When two routers attached to a
network both attempt to become Designated Router, the one
with the highest Router Priority takes precedence. If there
is still a tie, the router with the highest Router ID takes
precedence. A router whose Router Priority is set to 0 is
ineligible to become Designated Router on the attached
network. Router Priority is only configured for interfaces
to multi-access networks.
HelloInterval
The length of time, in seconds, between the Hello Packets
that the router sends on the interface. This value is
advertised in the router's Hello Packets. It must be the
same for all routers attached to a common network. The
smaller the HelloInterval, the faster topological changes
will be detected, but more OSPF routing protocol traffic
will ensue. Sample value for a X.25 PDN network: 30
seconds. Sample value for a local area network: 10 seconds.
RouterDeadInterval
After ceasing to hear a router's Hello Packets, the number
of seconds before its neighbors declare the router down.
This is also advertised in the router's Hello Packets in
their RouterDeadInterval field. This should be some
multiple of the HelloInterval (say 4). This value again
must be the same for all routers attached to a common
network.
Authentication key
This configured data allows the authentication procedure to
generate and/or verify the authentication field in the OSPF
header. This value again must be the same for all routers
attached to a common network. For example, if the AuType
indicates simple password, the Authentication key would be a
64-bit password. This key would be inserted directly into
the OSPF header when originating routing protocol packets.
There could be a separate password for each network.
C.4 Virtual link parameters
Virtual links are used to restore/increase connectivity of the
backbone. Virtual links may be configured between any pair of
area border routers having interfaces to a common (non-backbone)
area. The virtual link appears as an unnumbered point-to-point
link in the graph for the backbone. The virtual link must be
configured in both of the area border routers.
A virtual link appears in router links advertisements (for the
backbone) as if it were a separate router interface to the
backbone. As such, it has all of the parameters associated with
a router interface (see Section C.3). Although a virtual link
acts like an unnumbered point-to-point link, it does have an
associated IP interface address. This address is used as the IP
source in OSPF protocol packets it sends along the virtual link,
and is set dynamically during the routing table build process.
Interface output cost is also set dynamically on virtual links
to be the cost of the intra-area path between the two routers.
The parameter RxmtInterval must be configured, and should be
well over the expected round-trip delay between the two routers.
This may be hard to estimate for a virtual link; it is better to
err on the side of making it too large. Router Priority is not
used on virtual links.
A virtual link is defined by the following two configurable
parameters: the Router ID of the virtual link's other endpoint,
and the (non-backbone) area through which the virtual link runs
(referred to as the virtual link's Transit area). Virtual links
cannot be configured through stub areas.
C.5 Non-broadcast, multi-access network parameters
OSPF treats a non-broadcast, multi-access network much like it
treats a broadcast network. Since there may be many routers
attached to the network, a Designated Router is selected for the
network. This Designated Router then originates a networks
links advertisement, which lists all routers attached to the
non-broadcast network.
However, due to the lack of broadcast capabilities, it is
necessary to use configuration parameters in the Designated
Router selection. These parameters need only be configured in
those routers that are themselves eligible to become Designated
Router (i.e., those router's whose Router Priority for the
network is non-zero):
List of all other attached routers
The list of all other routers attached to the non-broadcast
network. Each router is listed by its IP interface address
on the network. Also, for each router listed, that router's
eligibility to become Designated Router must be defined.
When an interface to a non-broadcast network comes up, the
router sends Hello Packets only to those neighbors eligible
to become Designated Router, until the identity of the
Designated Router is discovered.
PollInterval
If a neighboring router has become inactive (Hello Packets
have not been seen for RouterDeadInterval seconds), it may
still be necessary to send Hello Packets to the dead
neighbor. These Hello Packets will be sent at the reduced
rate PollInterval, which should be much larger than
HelloInterval. Sample value for a PDN X.25 network: 2
minutes.
C.6 Host route parameters
Host routes are advertised in router links advertisements as
stub networks with mask 0xffffffff. They indicate either router
interfaces to point-to-point networks, looped router interfaces,
or IP hosts that are directly connected to the router (e.g., via
a SLIP line). For each host directly connected to the router,
the following items must be configured:
Host IP address
The IP address of the host.
Cost of link to host
The cost of sending a packet to the host, in terms of the
link state metric. There may be multiple costs configured,
one for each IP TOS. However, since the host probably has
only a single connection to the internet, the actual
configured cost(s) in many cases is unimportant (i.e., will
have no effect on routing).
D. Authentication All OSPF protocol exchanges are authenticated. The OSPF packet header (see Section A.3.1) includes an authentication type field, and 64-bits of data for use by the appropriate authentication scheme (determined by the type field). The authentication type is configurable on a per-area basis. Additional authentication data is configurable on a per-interface basis. For example, if an area uses a simple password scheme for authentication, a separate password may be configured for each network contained in the area. Authentication types 0 and 1 are defined by this specification. All other authentication types are reserved for definition by the IANA (iana@ISI.EDU). The current list of authentication types is described below in Table 20. AuType Description ___________________________________________ 0 No authentication 1 Simple password All others Reserved for assignment by the IANA (iana@ISI.EDU) Table 20: OSPF authentication types. D.1 AuType 0 -- No authentication Use of this authentication type means that routing exchanges in the area are not authenticated. The 64-bit field in the OSPF header can contain anything; it is not examined on packet reception. D.2 AuType 1 -- Simple password Using this authentication type, a 64-bit field is configured on a per-network basis. All packets sent on a particular network must have this configured value in their OSPF header 64-bit authentication field. This essentially serves as a "clear" 64- bit password.
This guards against routers inadvertently joining the area.
They must first be configured with their attached networks'
passwords before they can participate in the routing domain.
E. Differences from RFC 1247 This section documents the differences between this memo and RFC 1247. These differences include a fix for a problem involving OSPF virtual links, together with minor enhancements and clarifications to the protocol. All differences are backward-compatible. Implementations of this memo and of RFC 1247 will interoperate. E.1 A fix for a problem with OSPF Virtual links In RFC 1247, certain configurations of OSPF virtual links can cause routing loops. The root of the problem is that while there is an information mismatch at the boundary of any virtual link's Transit area, a backbone path can still cross the boundary. RFC 1247 attempted to compensate for this information mismatch by adjusting any backbone path as it enters the transit area (see Section 16.3 in RFC 1247). However, this proved not to be enough. This memo fixes the problem by having all area border routers determine, by looking at summary links, whether better backbone paths can be found through the transit areas. This fix simplifies the OSPF virtual link logic, and consists of the following components: o A new bit has been defined in the router links advertisement, called bit V. Bit V is set in a router's router links advertisement for Area A if and only if the router is an endpoint of an active virtual link that uses Area A as its Transit area (see Sections 12.4.1 and A.4.2). This enables the other routers attached to Area A to discover whether the area supports any virtual links (i.e., is a transit area). This discovery is done during the calculation of Area A's shortest-path tree (see Section 16.1). o To aid in the description of the algorithm, a new parameter has been added to the OSPF area structure: TransitCapability. This parameter indicates whether the area supports any active virtual links. Equivalently, it indicates whether the area can carry traffic that neither originates nor terminates in the area itself. o The calculation in Section 16.3 of RFC 1247 has been replaced. The new calculation, performed by area border routers only, examines the summary links belonging to all attached transit areas to see whether the transit areas can provide better paths than those already found in Sections 16.1 and 16.2.
o The incremental calculations in Section 16.5 have been
updated as a result of the new calculations in Section 16.3.
E.2 Supporting supernetting and subnet 0
In RFC 1247, an OSPF router cannot originate separate AS
external link advertisements (or separate summary link
advertisements) for two networks that have the same address but
different masks. This situation can arise when subnet 0 of a
network has been assigned (a practice that is generally
discouraged), or when using supernetting as described in [RFC
1519] (a practice that is generally encouraged to reduce the
size of routing tables), or even when in transition from one
mask to another on a subnet. Using supernetting as an example,
you might want to aggregate the four class C networks
192.9.4.0-192.9.7.0, advertising one route for the aggregation
and another for the single class C network 192.9.4.0.
The reason behind this limitation is that in RFC 1247, the Link
State ID of AS external link advertisements and summary link
advertisements is set equal to the described network's IP
address. In the above example, RFC 1247 would assign both
advertisements the Link State ID of 192.9.4.0, making them in
essence the same advertisement. This memo fixes the problem by
relaxing the setting of the Link State ID so that any of the
"host" bits of the network address can also be set. This allows
you to disambiguate advertisements for networks having the same
address but different masks. Given an AS external link
advertisement (or a summary link advertisement), the described
network's address can now be obtained by masking the Link State
ID with the network mask carried in the body of the
advertisement. Again using the above example, the aggregate can
now be advertised using a Link State ID of 192.9.4.0 and the
single class C network advertised simultaneously using the Link
State ID of 192.9.4.255.
Appendix F gives one possible algorithm for setting one or more
"host" bits in the Link State ID in order to disambiguate
advertisements. It should be noted that this is a local
decision. Each router in an OSPF system is free to use its own
algorithm, since only those advertisements originated by the
router itself are affected.
It is believed that this change will be more or less compatible
with implementations of RFC 1247. Implementations of RFC 1247
will probably either a) install routing table entries that won't
be used or b) do the correct processing as outlined in this memo
or c) mark the advertisement as unusable when presented with a
Link State ID that has one or more of the host bits set.
However, in the interest of interoperability, implementations of
this memo should only set the host bits in Link State IDs when
absolutely necessary.
The change affects Sections 12.1.4, 12.4.3, 12.4.5, 16.2, 16.3,
16.4, 16.5, 16.6, A.4.4 and A.4.5.
E.3 Obsoleting LSInfinity in router links advertisements
The metric of LSInfinity can no longer be used in router links
advertisements to indicate unusable links. This is being done
for several reasons:
o It removes any possible confusion in an OSPF area as to just
which routers/networks are reachable in the area. For
example, the above virtual link fix relies on detecting the
existence of virtual links when running the Dijkstra.
However, when one-directional links (i.e., cost of
LSInfinity in one direction, but not the other) are
possible, some routers may detect the existence of virtual
links while others may not. This may defeat the fix for the
virtual link problem.
o It also helps OSPF's Multicast routing extensions (MOSPF),
because one-way reachability can lead to places that are
reachable via unicast but not multicast, or vice versa.
The two prior justifications for using LSInfinity in router
links advertisements were 1) it was a way to not support TOS
before TOS was optional and 2) it went along with strong TOS
interpretations. These justifications are no longer valid.
However, LSInfinity will continue to mean "unreachable" in
summary link advertisements and AS external link advertisements,
as some implementations use this as an alternative to the
premature aging procedure specified in Section 14.1.
This change has one other side effect. When two routers are
connected via a virtual link whose underlying path is non-TOS-
capable, they must now revert to being non-TOS-capable routers
themselves, instead of the previous behavior of advertising the
non-zero TOS costs of the virtual link as LSInfinity. See
Section 15 for details.
E.4 TOS encoding updated
The encoding of TOS in OSPF link state advertisements has been
updated to reflect the new TOS value (minimize monetary cost)
defined by [RFC 1349]. The OSPF encoding is defined in Section
12.3, which is identical in content to Section A.5 of [RFC
1349].
E.5 Summarizing routes into transit areas
RFC 1247 mandated that routes associated with Area A are never
summarized back into Area A. However, this memo further reduces
the number of summary links originated by refusing to summarize
into Area A those routes having next hops belonging to Area A.
This is an optimization over RFC 1247 behavior when virtual
links are present. For example, in the area configuration of
Figure 6, Router RT11 need only originate a single summary link
having the (collapsed) destination N9-N11,H1 into its connected
transit area Area 2, since all of its other eligible routes have
next hops belonging to Area 2 (and as such only need be
advertised by other area border routers; in this case, Routers
RT10 and RT7). This is the logical equivalent of a Distance
Vector protocol's split horizon logic.
This change appears in Section 12.4.3.
E.6 Summarizing routes into stub areas
RFC 1247 mandated that area border routers attached to stub
areas must summarize all inter-area routes into the stub areas.
However, while area border routers connected to OSPF stub areas
must originate default summary links into the stub area, they
need not summarize other routes into the stub area. The amount
of summarization done into stub areas can instead be put under
configuration control. The network administrator can then make
the trade-off between optimal routing and database size.
This change appears in Sections 12.4.3 and 12.4.4.
E.7 Flushing anomalous network links advertisements
Text was added indicating that a network links advertisement
whose Link State ID is equal to one of the router's own IP
interface addresses should be considered to be self-originated,
regardless of the setting of the advertisement's Advertising
Router. If the Advertising Router of such an advertisement is
not equal to the router's own Router ID, the advertisement
should be flushed from the routing domain using the premature
aging procedure specified in Section 14.1. This case should be
rare, and it indicates that the router's Router ID has changed
since originating the advertisement.
Failure to flush these anomalous advertisements could lead to
multiple network links advertisements having the same Link State
ID. This in turn could cause the Dijkstra calculation in Section
16.1 to fail, since it would be impossible to tell which network
links advertisement is valid (i.e., more recent).
This change appears in Sections 13.4 and 14.1.
E.8 Required Statistics appendix deleted
Appendix D of RFC 1247, which specified a list of required
statistics for an OSPF implementation, has been deleted. That
appendix has been superseded by the two documents: the OSPF
Version 2 Management Information Base and the OSPF Version 2
Traps.
E.9 Other changes
The following small changes were also made to RFC 1247:
o When representing unnumbered point-to-point networks in
router links advertisements, the corresponding Link Data
field should be set to the unnumbered interface's MIB-II
[RFC 1213] ifIndex value.
o A comment was added to Step 3 of the Dijkstra algorithm in
Section 16.1. When removing vertices from the candidate
list, and when there is a choice of vertices closest to the
root, network vertices must be chosen before router vertices
in order to necessarily find all equal-cost paths.
o A comment was added to Section 12.4.3 noting that a summary
link advertisement cannot express a reachable destination
whose path cost equals or exceeds LSInfinity.
o A comment was added to Section 15 noting that a virtual link
whose underlying path has cost greater than hexadecimal
0xffff (the maximum size of an interface cost in a router
links advertisement) should be considered inoperational.
o An option was added to the definition of area address
ranges, allowing the network administrator to specify that a
particular range should not be advertised to other OSPF
areas. This enables the existence of certain networks to be
hidden from other areas. This change appears in Sections
12.4.3 and C.2.
o A note was added reminding implementors that bit E (the AS
boundary router indication) should never be set in a router
links advertisement for a stub area, since stub areas cannot
contain AS boundary routers. This change appears in Section
12.4.1.
F. An algorithm for assigning Link State IDs In RFC 1247, the Link State ID in AS external link advertisements and summary link advertisements is set to the described network's IP address. This memo relaxes that requirement, allowing one or more of the network's host bits to be set in the Link State ID. This allows the router to originate separate advertisements for networks having the same addresses, yet different masks. Such networks can occur in the presence of supernetting and subnet 0s (see Section E.2 for more information). This appendix gives one possible algorithm for setting the host bits in Link State IDs. The choice of such an algorithm is a local decision. Separate routers are free to use different algorithms, since the only advertisements affected are the ones that the router itself originates. The only requirement on the algorithms used is that the network's IP address should be used as the Link State ID (the RFC 1247 behavior) whenever possible. The algorithm below is stated for AS external link advertisements. This is only for clarity; the exact same algorithm can be used for summary link advertisements. Suppose that the router wishes to originate an AS external link advertisement for a network having address NA and mask NM1. The following steps are then used to determine the advertisement's Link State ID: (1) Determine whether the router is already originating an AS external link advertisement with Link State ID equal to NA (in such an advertisement the router itself will be listed as the advertisement's Advertising Router). If not, set the Link State ID equal to NA (the RFC 1247 behavior) and the algorithm terminates. Otherwise, (2) Obtain the network mask from the body of the already existing AS external link advertisement. Call this mask NM2. There are then two cases: o NM1 is longer (i.e., more specific) than NM2. In this case, set the Link State ID in the new advertisement to be the network [NA,NM1] with all the host bits set (i.e., equal to NA or'ed together with all the bits that are not set in NM1, which is network [NA,NM1]'s broadcast address). o NM2 is longer than NM1. In this case, change the existing advertisement (having Link State ID of NA) to reference the new network [NA,NM1] by incrementing the sequence number, changing the mask in the body to NM1 and using the cost for the new network. Then originate a new advertisement for the
old network [NA,NM2], with Link State ID equal to NA or'ed
together with the bits that are not set in NM2 (i.e.,
network [NA,NM2]'s broadcast address).
The above algorithm assumes that all masks are contiguous; this
ensures that when two networks have the same address, one mask is
more specific than the other. The algorithm also assumes that no
network exists having an address equal to another network's
broadcast address. Given these two assumptions, the above algorithm
always produces unique Link State IDs. The above algorithm can also
be reworded as follows: When originating an AS external link state
advertisement, try to use the network number as the Link State ID.
If that produces a conflict, examine the two networks in conflict.
One will be a subset of the other. For the less specific network,
use the network number as the Link State ID and for the more
specific use the network's broadcast address instead (i.e., flip all
the "host" bits to 1). If the most specific network was originated
first, this will cause you to originate two link state
advertisements at once.
As an example of the algorithm, consider its operation when the
following sequence of events occurs in a single router (Router A).
(1) Router A wants to originate an AS external link advertisement
for [10.0.0.0,255.255.255.0]:
(a) A Link State ID of 10.0.0.0 is used.
(2) Router A then wants to originate an AS external link
advertisement for [10.0.0.0,255.255.0.0]:
(a) The advertisement for [10.0.0,0,255.255.255.0] is
reoriginated using a new Link State ID of 10.0.0.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.255.0.0].
(3) Router A then wants to originate an AS external link
advertisement for [10.0.0.0,255.0.0.0]:
(a) The advertisement for [10.0.0.0,255.255.0.0] is reoriginated
using a new Link State ID of 10.0.255.255.
(b) A Link State ID of 10.0.0.0 is used for
[10.0.0.0,255.0.0.0].
(c) The network [10.0.0.0,255.255.255.0] keeps its Link State ID
of 10.0.0.255.
Security Considerations All OSPF protocol exchanges are authenticated. This is accomplished through authentication fields contained in the OSPF packet header. For more information, see Sections 8.1, 8.2, and Appendix D. Author's Address John Moy Proteon, Inc. 9 Technology Drive Westborough, MA 01581 Phone: 508-898-2800 Fax: 508-898-3176 Email: jmoy@proteon.com