RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 9 records.

Status: Verified (8)

RFC 2328, "OSPF Version 2", April 1998

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

Status: Reported (1)

RFC 2328, "OSPF Version 2", April 1998

Source of RFC: ospf (rtg)

Errata ID: 6679
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Nikolai Malykh
Date Reported: 2021-09-07

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).

Report New Errata