RFC Errata
Found 13 records.
Status: Verified (11)
RFC 2328, "OSPF Version 2", April 1998
Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454
Source of RFC: ospf (rtg)
Errata ID: 2953
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Joel Gannett
Date Reported: 2011-08-31
Verifier Name: Stewart Bryant
Date Verified: 2011-09-02
Section 3.4 says:
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 18
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
It should say:
Destination RT3 adv. RT4 adv.
_________________________________
Ia,Ib 20 27
N6 16 15
N7 20 19
N8 18 25
N9-N11,H1 29 36
_________________________________
RT5 14 8
RT7 20 14
Table 6: Destinations advertised into Area 1
by Routers RT3 and RT4.
Notes:
The distance from RT4 to N8 should be changed from 18 to 25. Unless there is a virtual link between RT7 and RT10, the shortest path from RT4 to N8 is 25, not 18. Although a virtual link from RT7 and RT10 is discussed in the last paragraph of Section 3.4, it is not assume part of the network design. Moreover, this change is needed to make the N9-N11,H1 row consistent with the N8 row, as each entry in the N9-N11,H1 row must be 11 greater than the same-column entry in the N8 row.
Errata ID: 3746
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-10-09
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10
Throughout the document, when it says:
*. Section 3.3. (Classification of routers) says:
AS boundary routers
A router that exchanges routing information with routers
belonging to other Autonomous Systems. Such a router
advertises AS external routing information throughout the
Autonomous System. The paths to each AS boundary router are
known by every router in the AS. This classification is
completely independent of the previous classifications: AS
boundary routers may be internal or area border routers, and
may or may not participate in the backbone.
*. Section 10.6 (Receiving Database Description Packets) says:
When the router accepts a received Database Description Packet
as the next in sequence the packet contents are processed as
follows. For each LSA listed, the LSA's LS type is checked for
validity. If the LS type is unknown (e.g., not one of the LS
types 1-5 defined by this specification), or if this is an AS-
external-LSA (LS type = 5) and the neighbor is associated with a
stub area, generate the neighbor event SeqNumberMismatch and
stop processing the packet.
*. Section 13. (The Flooding Procedure) says:
(3) Else if this is an AS-external-LSA (LS type = 5), and the area
has been configured as a stub area, discard the LSA and get the
next one from the Link State Update Packet. AS-external-LSAs
are not flooded into/throughout stub areas (see Section 3.6).
(4) Else if the LSA's LS age is equal to MaxAge, and there is
currently no instance of the LSA in the router's link state
database, and none of router's neighbors are in states Exchange
It should say:
*. Section 3.3. (Classification of routers) should say:
AS boundary routers
A router that exchanges routing information with routers
belonging to other Autonomous Systems. Such a router
advertises AS external routing information throughout the
Autonomous System. The paths to each AS boundary router are
known by every router in the AS (except stub areas). This
classification is
completely independent of the previous classifications: AS
boundary routers may be internal or area border routers, and
may or may not participate in the backbone.
*. Section 10.6 (Receiving Database Description Packets) should say:
When the router accepts a received Database Description Packet
as the next in sequence the packet contents are processed as
follows. For each LSA listed, the LSA's LS type is checked for
validity. If the LS type is unknown (e.g., not one of the LS
types 1-5 defined by this specification), or if this is an AS-
external-LSA (LS type = 5) and the neighbor is associated with a
stub area, or if this is a type-4 summary LSA and the neighbor
is associated with a stub area, generate the neighbor event
SeqNumberMismatch and stop processing the packet.
*. Section 13. (The Flooding Procedure) should say:
There should be an additional step in between steps 3 and 4 in
Section 13. The additional step below is denoted 3.5:
(3) Else if this is an AS-external-LSA (LS type = 5), and the area
has been configured as a stub area, discard the LSA and get the
next one from the Link State Update Packet. AS-external-LSAs
are not flooded into/throughout stub areas (see Section 3.6).
(3.5) Else if this is a type-4 Summary LSA (LS type = 4), and the
area has been configured as a stub area, discard the LSA and get
the next one from the Link State Update Packet. Type-4 Summary
LSAs are not flooded into/throughout stub areas.
(4) Else if the LSA's LS age is equal to MaxAge, and there is
currently no instance of the LSA in the router's link state
database, and none of router's neighbors are in states Exchange
Notes:
This whole note is regarding stub areas.
RFC 2328 is already consistent with respect to AS-external-LSAs
(LS type =5). The RFC explicitly indicates that they should be neither
sent nor received in stub areas.
But RFC 2328 seems to have some omissions with respect to type-4
Summary LSA (LS type = 4). The RFC explicitly indicates that these
LSAs should never be sent in stub areas. But it does not mention what
should be done if these LSAs are received in stub areas.
The above updates try to remedy this omission.
If the neighbor is associated with a stub area, then we should never
receive a type-4 summary LSA from that neighbor. Here are the relevant
quotes from the RFC:
Section 12.4.3.1.(Originating summary-LSAs into stub areas):
"As specified in Section 12.4.3, Type 4 summary-LSAs
(ASBR-summary-LSAs) are never originated into stub
areas."
Section 4.2. (AS external routes):
"To utilize external routing information, the path to all routers
advertising external information must be known throughout the AS
(excepting the stub areas). For that reason, the locations of
these AS boundary routers are summarized by the (non-stub) area
border routers."
This is an omission from RFC 2328.
http://www.ietf.org/mail-archive/web/ospf/current/msg06720.html
Errata ID: 3974
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mike Dubrovsky
Date Reported: 2014-04-24
Verifier Name: Alia Atlas
Date Verified: 2014-05-12
Section 13 says:
(6) Else, if there is an instance of the LSA on the sending
neighbor's Link state request list, an error has occurred in the
Database Exchange process. In this case, restart the Database
Exchange process by generating the neighbor event BadLSReq for
the sending neighbor and stop processing the Link State Update
packet.
(7) Else, if the received LSA is the same instance as the database
copy (i.e., neither one is more recent) the following two steps
should be performed:
(a) If the LSA is listed in the Link state retransmission list
for the receiving adjacency, the router itself is expecting
an acknowledgment for this LSA. The router should treat the
received LSA as an acknowledgment by removing the LSA from
the Link state retransmission list. This is termed an
"implied acknowledgment". Its occurrence should be noted
for later use by the acknowledgment process (Section 13.5).
(b) Possibly acknowledge the receipt of the LSA by sending a
Link State Acknowledgment packet back out the receiving
interface. This is explained below in Section 13.5.
It should say:
(6) Else, if the received LSA is the same instance as the database
copy (i.e., neither one is more recent) the following two steps
should be performed:
(a) If the LSA is listed in the Link state retransmission list
for the receiving adjacency, the router itself is expecting
an acknowledgment for this LSA. The router should treat the
received LSA as an acknowledgment by removing the LSA from
the Link state retransmission list. This is termed an
"implied acknowledgment". Its occurrence should be noted
for later use by the acknowledgment process (Section 13.5).
(b) Possibly acknowledge the receipt of the LSA by sending a
Link State Acknowledgment packet back out the receiving
interface. This is explained below in Section 13.5.
(7) Else, if there is an instance of the LSA on the sending
neighbor's Link state request list, an error has occurred in the
Database Exchange process. In this case, restart the Database
Exchange process by generating the neighbor event BadLSReq for
the sending neighbor and stop processing the Link State Update
packet.
Notes:
The problem arises when the routing domain has two instances of LSA
with the same sequence number and the same checksum,
but with an age difference bigger than MaxAgeDiff.
The above could take place in multiple scenarios. Here are two examples:
1) There is a demand circuit somewhere in the routing domain
2) The router lost its ASBR status and therefore flushed the self-originated Type 5 LSAs
but later on gained the ASBR status back and re-originated Type 5.
If the network was partitioned, each partition can have two instances of LSA
with an age difference bigger than MaxAgeDiff.
The two instances of LSA can temporarily prevent the adjacency formation.
Consider the example below:
Topology
========
RT1 ----- RT2
Initial state:
==============
The physical link between RT1 and R2 just came up
The routers are about to form ospf adjacency.
Initial link-state databases:
=============================
R1 ospf database has LSA 10.0.0.1 age 910 seq # 0x80000001
R2 ospf database has the same LSA 10.0.0.1 age 9 seq # 0x80000001
RT1 Event Sequence:
===============
RT1 is starting to form adjacency with RT2.
1) During the Database Exchange, RT2's LSA instance is more recent because of more than 900 (MaxAgeDiff) seconds age difference (section 13.1 of RFC 2328).
2) So RT1 requests the LSA
3) RT2 sends the LSA after incrementing the age by 1 (InfTransDelay).
4) When the LSA instance arrives to RT1, it is identical (the difference is exactly 900 seconds now).
So RT1 aborts Loading according to step (6) of section 13.
Solution:
=========
Swap steps (6) and (7) of section 13.
Acee Lindem adds:
"This situation comes into play when a router views an LSA as being
more recent when the LSA is requested (via Link-State Request) but as the
same instance when the LSA is actually received."
Errata ID: 4022
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2014-06-23
Verifier Name: Alia Atlas
Date Verified: 2014-06-24
Section 10.5 says:
When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For these network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address.
It should say:
When receiving an Hello Packet from a neighbor on a broadcast, Point-to-MultiPoint or NBMA network, set the neighbor structure's Neighbor ID equal to the Router ID found in the packet's OSPF header. For broadcast and NBMA network types, the neighbor structure's Router Priority field, Neighbor's Designated Router field, and Neighbor's Backup Designated Router field are also set equal to the corresponding fields found in the received Hello Packet; changes in these fields should be noted for possible use in the steps below. When receiving an Hello on a point-to-point network (but not on a virtual link) set the neighbor structure's Neighbor IP address to the packet's IP source address.
Notes:
This is unnecessary in case of Point-to-MultiPoint network type to hold neighbor's Router Priority, DR, and BDR values.
Errata ID: 3734
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna DTV
Date Reported: 2013-09-23
Verifier Name: Stewart Bryant
Date Verified: 2013-10-10
Section 8.2 says:
The AuType specified in the packet must match the AuType
specified for the associated area.
It should say:
The AuType specified in the packet must match the AuType
specified for the associated interface.
Notes:
In OSPFv2, authentication is configured per interface and not per area.
Appendix D clarifies this: "The authentication type is configurable on a per-interface
(or equivalently, on a per-network/subnet) basis."
Errata ID: 4023
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alexander Okonnikov
Date Reported: 2014-06-24
Verifier Name: Alia Atlas
Date Verified: 2014-06-24
Section 12.4.1 says:
o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for virtual links in Section 12.4.1.2, for broadcast and NBMA interfaces in 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4.
It should say:
o Otherwise, the link descriptions added to the router-LSA depend on the OSPF interface type. Link descriptions used for point-to-point interfaces are specified in Section 12.4.1.1, for broadcast and NBMA interfaces in 12.4.1.2, for virtual links in Section 12.4.1.3, and for Point-to-MultiPoint interfaces in 12.4.1.4.
Notes:
Incorrect references.
Errata ID: 4330
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Ramakrishna Rao DTV
Date Reported: 2015-04-08
Verifier Name: Alia Atlas
Date Verified: 2015-04-09
Section 3.4 says:
The link-state database for the backbone is shown in Figure 8.
The set of routers pictured are the backbone routers. Router
RT11 is a backbone router because it belongs to two areas. In
order to make the backbone connected, a virtual link has been
configured between Routers R10 and R11.
It should say:
The link-state database for the backbone is shown in Figure 8.
The set of routers pictured are the backbone routers. Router
RT11 is a backbone router because it belongs to two areas. In
order to make the backbone connected, a virtual link has been
configured between Routers RT10 and RT11.
Notes:
s/R10/RT10
s/R11/RT11
Errata ID: 5041
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Augustyn
Date Reported: 2017-06-13
Verifier Name: Alia Atlas
Date Verified: 2017-06-13
Section 10.2 says:
1-Way
An Hello packet has been received from the neighbor, in
which the router is not mentioned. This indicates that
communication with the neighbor is not bidirectional.
It should say:
1-WayReceived
An Hello packet has been received from the neighbor, in
which the router is not mentioned. This indicates that
communication with the neighbor is not bidirectional.
Notes:
RFC2328 defines The Neighbor state machine and it's states. One of the states is defined/named as 1-WayReceived ([Page 95] 10.3.).
1-WayReceived is also mentioned on page 84 and 98.
Pages 85 and 88 use event 1Way which should be renamed to 1-WayReceived for consistency with definition of the state.
[Page 85]
Event 1-Way forces Init state,
[Page 88]
10.2. Events causing neighbor state changes
1-Way
An Hello packet has been received from the neighbor, in
which the router is not mentioned. This indicates that
communication with the neighbor is not bidirectional.
On p. 85 after Figure 13, it says "Figure 13: Neighbor state changes (Database Exchange)
....
Event 1-Way forces Init state,
"
and Event 1-Way should be replaced with 1-WayReceived
Errata ID: 6679
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Nikolai Malykh
Date Reported: 2021-09-07
Verifier Name: John Scudder
Date Verified: 2022-05-09
Section 3.4 says:
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the dashed stubs that
appear in Figure 8. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single dashed line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
It should say:
The area border routers RT3, RT4, RT7, RT10 and RT11 condense
the routing information of their attached non-backbone areas for
distribution via the backbone; these are the dashed stubs that
appear in Figure 6. Remember that the third area has been
configured to condense Networks N9-N11 and Host H1 into a single
route. This yields a single dashed line for networks N9-N11 and
Host H1 in Figure 8. Routers RT5 and RT7 are AS boundary
routers; their externally derived information also appears on
the graph in Figure 8 as stubs.
Notes:
Incorrect figure number (8 instead 6).
Errata ID: 7112
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Renato Westphal
Date Reported: 2022-09-01
Verifier Name: John Scudder
Date Verified: 2022-09-01
Section 10.2 says:
NegotiationDone
The Master/Slave relationship has been negotiated, and DD
sequence numbers have been exchanged. This signals the
start of the sending/receiving of Database Description
packets. For more information on the generation of this
event, consult Section 10.8.
It should say:
NegotiationDone
The Master/Slave relationship has been negotiated, and DD
sequence numbers have been exchanged. This signals the
start of the sending/receiving of Database Description
packets. For more information on the generation of this
event, consult Section 10.6.
Notes:
The generation of the NegotiationDone event is specified in Section 10.6 (not Section 10.8).
(Also discussed at https://mailarchive.ietf.org/arch/msg/lsr/NZMWapi62sJuExnBZFBBMdW169k/)
Errata ID: 7756
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Lokesh Venkata Kumar Chakka
Date Reported: 2024-01-11
Verifier Name: John Scudder
Date Verified: 2024-01-11
Section A.4.5 says:
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by
AS boundary routers, and describe destinations external to the AS.
For details concerning the construction of AS-external-LSAs, see
Section 12.4.3.
It should say:
AS-external-LSAs are the Type 5 LSAs. These LSAs are originated by
AS boundary routers, and describe destinations external to the AS.
For details concerning the construction of AS-external-LSAs, see
Section 12.4.4.
Notes:
Incorrect references. Construction of AS-external-LSAs explained in Section 12.4.4. Not in 12.4.
(See also https://mailarchive.ietf.org/arch/msg/lsr/OiOvEPM2W-Mwd_QgbmJASg8bDOI/)
Status: Reported (2)
RFC 2328, "OSPF Version 2", April 1998
Note: This RFC has been updated by RFC 5709, RFC 6549, RFC 6845, RFC 6860, RFC 7474, RFC 8042, RFC 9355, RFC 9454
Source of RFC: ospf (rtg)
Errata ID: 7850
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Lindem
Date Reported: 2024-03-15
Section 10.7/A.3.5 says:
Section 10.7
Each LSA specified in the Link State Request packet should be
located in the router's database, and copied into Link State
Update packets for transmission to the neighbor. These LSAs
should NOT be placed on the Link state retransmission list for
the neighbor. If an LSA cannot be found in the database,
something has gone wrong with the Database Exchange process, and
neighbor event BadLSReq should be generated.
Section A.3.5
Link State Update packets are multicast on those physical networks
that support multicast/broadcast. In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets. If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always sent directly to the
neighbor. For more information on the reliable flooding of LSAs,
consult Section 13.
It should say:
Section 10.7
Each LSA specified in the Link State Request packet should be
located in the router's database, and copied into Link State
Update packets for transmission directly to the neighbor,
i.e., unicast on all interface types except point-to-point
interfaces where all OSPF packets are sent to the address
AllSPFRouters. These LSAs should NOT be placed on the Link
state retransmission list for the neighbor. If an LSA cannot
be found in the database, something has gone wrong with the
Database Exchange process, and neighbor event BadLSReq should
be generated.
Section A.3.5
Link State Update packets are multicast on those physical networks
that support multicast/broadcast. In order to make the flooding
procedure reliable, flooded LSAs are acknowledged in Link State
Acknowledgment packets. If retransmission of certain LSAs is
necessary, the retransmitted LSAs are always sent directly to the
neighbor. For more information on the reliable flooding of LSAs,
consult Section 13. Link State Update packets are also sent
directly to the neighbor in response to Link State Request
packets as specified in Section 10.7.
Notes:
Clarify that OSPF Link State Updates sent in response to OSPF Link Requests should be unicast.
Errata ID: 7851
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Acee Lindem
Date Reported: 2024-03-15
Section 8.1 says:
Retransmissions of Link State Update packets are ALWAYS sent
directly to the neighbor. On multi-access networks, this means
that retransmissions should be sent to the neighbor's IP
address.
It should say:
Retransmissions of Link State Update packets and Link State
Update packets sent in response to Link State Request packets
are ALWAYS sent directly to the neighbor. On multi-access
networks, this means that retransmissions should be sent to
the neighbor's IP address.
Notes:
One more place requiring clarification with respect to the Link State Update packets sent in response to Link State Request packets.