RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 15 records.

Status: Verified (7)

RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016

Source of RFC: INDEPENDENT

Errata ID: 5030
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Travis P. Bonfigli
Date Reported: 2017-06-06
Verifier Name: Nevil Brownlee
Date Verified: 2017-07-20

Section 6.7.4 says:

6.7.4.  0x0004 - SOFTWARE_VERSION_TYPE

           Field                        Length
           Vender OS major version        1
           Vender OS minor version        1
           EIGRP major revision           1
           EIGRP minor revision           1

   The EIGRP TLV Version fields are used to determine TLV format
   versions.  Routers using Version 1.2 TLVs do not understand Version
   2.0 TLVs, therefore Version 2.0 routers must send the packet with
   both TLV formats in a mixed network.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0004             |            0x000C             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

6.7.4.  0x0004 - SOFTWARE_VERSION_TYPE

           Field                        Length
           Vender OS major version        1
           Vender OS minor version        1
           EIGRP major revision           1
           EIGRP minor revision           1

   The EIGRP TLV Version fields are used to determine TLV format
   versions.  Routers using Version 1.2 TLVs do not understand Version
   2.0 TLVs, therefore Version 2.0 routers must send the packet with
   both TLV formats in a mixed network.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |            0x0004             |            0x0008             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Vendor Major V.|Vendor Minor V.| EIGRP Major V.| EIGRP Minor V.|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

Hello! In looking over the TLV construct in Section 6.7.4 0x0004 - SOFTWARE_VERSION_TYPE it appears that they might be a 'typo' with respect to the 'Length' value provided in the RFC diagram. The current value is shown as 0x000C (12 bytes), but in reality it appears that it should be 0x0008 (8 bytes) given the format/length of the specific TLV being discussed. Thank you.

Cheers,
Travis

Errata ID: 5952
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Christopher Hart
Date Reported: 2019-12-30
Verifier Name: Adrian Farrel
Date Verified: 2020-01-19

Section 6.5 says:

   RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE
      packets during the restart period.  The router looks at the RS-
      Flag to detect if a neighbor is restarting.  From the restarting
      routers perspective, if a neighboring router detects the RS-Flag
      set, it will maintain the adjacency, and will set the RS-Flag in
      its UPDATE packet to indicated it is doing a soft restart.

It should say:

   RS-Flag (0x04): The Restart flag is set in the HELLO and the UPDATE
      packets during the restart period.  A router looks at the RS-
      Flag to detect if a neighbor is restarting.  From the restarting
      router's perspective, if a neighboring router detects the RS-
      Flag is set, the neighboring router will maintain the adjacency
      with the restarting router. The restarting router will set the
      RS-Flag in its UPDATE packet to indicate it is performing a soft
      restart.

Notes:

Cleaning up the grammar for the RS-Flag portion of Section 6.5. The grammar used in the original text can be ambiguously interpreted as to whether the restarting router initially sets the RS-Flag in its Update packet, or the neighboring router initially sets the RS-Flag in its Update packet.

Errata ID: 6086
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-11
Verifier Name: RFC Editor
Date Verified: 2020-04-21

Section 5.4.2. says:

   Routes learned
   though interfaces that EIGRP is NOT using to reach the destination
   may have the route advertised out those interfaces.

It should say:

   Routes learned
   through interfaces that EIGRP is NOT using to reach the destination
   may have the route advertised out those interfaces.

Notes:

Typo in 'through' word.

Errata ID: 6092
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Verifier Name: Adrian Farrel
Date Verified: 2020-04-22

Section 6.7.7. says:

0x0007 - PEER_ TERMINATION_TYPE

It should say:

0x0007 - PEER_TERMINATION_TYPE

Notes:

Removed extra space in section title.

Errata ID: 6318
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Stanislav Asanov
Date Reported: 2020-10-24
Verifier Name: Adrian Farrel
Date Verified: 2020-10-24

Section 6.6.1 says:

Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in
   Section 3.

It should say:

Type Low: 1 octet that defines the TLV Opcode; see TLV Definitions in
   Sections 6.7, 6.8, and 6.9.

Notes:

There are no TLV definitions in Section 3. The TLV Opcodes are defined in Sections 6.7, 6.8, 6.9.

Errata ID: 6320
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Stanislav Asanov
Date Reported: 2020-10-26
Verifier Name: Adrian Farrel
Date Verified: 2020-10-27

Section 6.9.3.8.1 says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07    |       Offset  | Next-Hop Addr. (Upper 2 bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | IPv4 Address (Lower 2 bytes)  |       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Upper 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Upper 2 bytes)     |Extern Protocol| Flags Field   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07    |       Offset  | Next-Hop Addr. (Upper 2 bytes)|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next-Hop Addr. (Lower 2 bytes)|       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Lower 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Lower 2 bytes)     |Extern Protocol| Flags Field   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

1. There is no subfield named "IPv4 Address" in AddPath field. The label in the 5th and 6th octets of the AddPath field is a typo, and it should read "Next-Hop Addr. (Lower 2 bytes)".
2. The subfield "RID (Upper 2 bytes)" is repeated in the AddPath field, and there is no subfield for lower 2 bytes of RID. The same with "Admin Tag (Upper 2 bytes)" subfield.

Errata ID: 6322
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Stanislav Asanov
Date Reported: 2020-10-27
Verifier Name: Adrian Farrel
Date Verified: 2020-10-29

Section 6.9.3.8.2. says:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07     |       Offset |         Next-Hop Address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                            (16 octets)                        |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                               |       RID (Upper 2 byes)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Upper 2 byes)     | Admin Tag (Upper 2 byes)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Upper 2 byes)      | Extern Protocol | Flags Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       0x07     |       Offset |         Next-Hop Address      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   |                            (16 octets)                        |
   |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
   |                               |       RID (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        RID (Lower 2 bytes)    | Admin Tag (Upper 2 bytes)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Admin Tag (Lower 2 bytes)     | Extern Protocol | Flags Field |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

The subfield "RID (Upper 2 bytes)" is repeated in the AddPath with IPv6 Next Hop field, and there is no subfield for lower 2 bytes of RID. The same with "Admin Tag (Upper 2 bytes)" subfield. Typo in the word "bytes".

Status: Reported (5)

RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016

Source of RFC: INDEPENDENT

Errata ID: 5242
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Innokentiy Solntsev
Date Reported: 2018-01-24
Edited by: Adrian Farrel
Date Edited: 2020-04-22

Section 5.6.2.5 says:

                                                                K5
      metric =[(K1*Net-Throughput) + Latency)+(K6*ExtAttr)] * ------
                                                              K4+Rel

It should say:

                                                        K5
      metric =[Net-Throughput+Latency+(K6*ExtAttr)] * ------
                                                      K4+Rel

Notes:

1. Round brackets aren't balanced.
2. There shouldn't be K1, as Net-Throughput already includes it.

Errata ID: 5691
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Gabriel Torres
Date Reported: 2019-04-14

Section 5.6.1.1 says:

The calculated EIGRP bandwidth (BW) metric is then:

               256 * (10^7)/BW = 256 * {(10^7)/10,000}
                               = 256 * 1000
                               = 256,000

   And the calculated EIGRP delay metric is then:

            256 * sum of delay = 256 * 100 * 10 microseconds
                               = 25,600 (in tens of microseconds)

It should say:

The calculated EIGRP bandwidth (BW) metric is then:

               (10^7)/BW = {(10^7)/10,000}
                         = 1,000

   And the calculated EIGRP delay metric is then:

               sum of delay = 1 ms = 100 tens of microseconds

   Thus the composite metric is:

               256 * 1000 * 100 = 25,600,000

Notes:

The 256 should be multiplied by the sum of the bandwidth and the delay, and not multiplied by each individual parameter.

1 ms = 1,000 microseconds = 100 tens of microseconds

Errata ID: 6084
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-10

Section 5.6.2.3. says:

   The formula for the conversion for Max-Throughput value directly from
   the interface without consideration of congestion-based effects is as
   follows:

                                  (EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE)
        Max-Throughput = K1 *     ------------------------------------
                                       Interface Bandwidth (kbps)


   If K2 is used, the effect of congestion as a measure of load reported
   by the interface will be used to simulate the "available Throughput"
   by adjusting the maximum Throughput according to the formula:

                                           K2 * Max-Throughput
        Net-Throughput = Max-Throughput + ---------------------
                                              256 - Load

It should say:

   The formula for the conversion for Max-Throughput value directly from
   the interface without consideration of congestion-based effects is as
   follows:

                           EIGRP_BANDWIDTH * EIGRP_WIDE_SCALE
        Max-Throughput =  ------------------------------------
                               Interface Bandwidth (kbps)


   If K2 is used, the effect of congestion as a measure of load reported
   by the interface will be used to simulate the "available Throughput"
   by adjusting the maximum Throughput according to the formula:

                                                K2 * Max-Throughput
        Net-Throughput = K1 * Max-Throughput + ---------------------
                                                     256 - Load

Notes:

K1 can't be a part of Max-Throughput as it affects Net-Throughput twice. Moreover: in case of K1=0, K2 become ignored as it will be multiplied by 0.

Together with errata ID: 5242 which fixes metric formula {metric =[Net-Throughput+Latency+(K6*ExtAttr)] * K5/(K4+Rel) }, results become correct and are same as on live equipment.

Errata ID: 6088
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12

Section 6.1. says:

   EIGRP IPv4 will transmit HELLO packets using either the unicast
   destination of a neighbor or using a multicast host group address [7]
   with a source address EIGRP IPv4 multicast address [13].

It should say:

   EIGRP IPv4 will transmit HELLO packets using either the unicast
   destination of a neighbor or using a multicast host group address [7]
   with a destination address EIGRP IPv4 multicast address [13].

Notes:

Multicast address is a destination address.

Errata ID: 6090
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12

Section 5.6.2.5. says:

metric = (K1 * min(Throughput)) + (K3 * sum(Latency)) }

It should say:

metric = K1 * Max-Throughput + Latency

Notes:

This errata is consequence of:
- erratas 5242 and 6084,
- inconsistency of using (Max-)Throughput and Latency variables,
- using additional min() and sum() functions which are not used in formula where all K-values takes effect ( metric =[Net-Throughput+Latency+(K6*ExtAttr)] * K5/(K4+Rel)) .

The Max-Throughput variable defined in 5.6.2.3. is a little bit unfortunate, as in fact it is minimum of maximum available throughput of all network segments in the path.

I removed also K3 value from the metric as it is already embraced in Latency calculation in 5.6.2.4.

I decided to use this formula as it is mathematically correct and is least intrusive but the best would be to review notations from 5.6.2.3. up to .5 and remove all inaccuracies. Also highlighting usage of K-Values in final metric calculation would make this document more readable, eg. metric = K1 * Throughtput + K3 * Latency - which shows best how K-values affect metric.

Status: Held for Document Update (3)

RFC 7868, "Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)", May 2016

Source of RFC: INDEPENDENT

Errata ID: 5185
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Varadhan Venkataseshan
Date Reported: 2017-11-21
Held for Document Update by: Adrian Farrel
Date Held: 2018-04-08

Section 6.9.3.5 says:

across a network measured in measured in microseconds.    

It should say:

across a network measured in microseconds.

Notes:

Words "measured in" is repeated twice at line number 3965 in section 6.9.3.5

Errata ID: 6089
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-22

Section 5.5.2 says:

    EIGRP uses one-way-
   based values either provided by the interface or computed as a factor
   of the link s bandwidth.

It should say:

    EIGRP uses one-way-
   based values either provided by the interface or computed as a factor
   of the link's bandwidth.

Notes:

Missing apostrophe (') in "link's".

Errata ID: 6091
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT

Reported By: Rafał Cygnarowski
Date Reported: 2020-04-12
Held for Document Update by: Adrian Farrel
Date Held: 2020-04-22

Section 6.7.4. says:

           Vender OS major version        1
           Vender OS minor version        1

It should say:

           Vendor OS major version        1
           Vendor OS minor version        1

Notes:

Typo in 'Vendor' word.

Report New Errata