tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7868

 
 
 

Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)

Part 2 of 4, p. 20 to 39
Prev RFC Part       Next RFC Part

 


prevText      Top      ToC       Page 20 
4.  EIGRP Packets

   EIGRP uses five different packet types to handle session management
   and pass DUAL Message types:

       HELLO Packets (includes ACK)
       QUERY Packets (includes SIA-Query)
       REPLY Packets (includes SIA-Reply)
       REQUEST Packets
       UPDATE Packets

   EIGRP packets are directly encapsulated into a network-layer
   protocol, such as IPv4 or IPv6.  While EIGRP is capable of using
   additional encapsulation (such as AppleTalk, IPX, etc.) no further
   encapsulation is specified in this document.

Top      Up      ToC       Page 21 
   Support for network-layer protocol fragmentation is not supported,
   and EIGRP will attempt to avoid a maximum size packets that exceed
   the interface MTU by sending multiple packets that are less than or
   equal to MTU-sized packets.

   Each packet transmitted will use either multicast or unicast network-
   layer destination addresses.  When multicast addresses are used, a
   mapping for the data link multicast address (when available) must be
   provided.  The source address will be set to the address of the
   sending interface, if applicable.

   The following network-layer multicast addresses and associated data
   link multicast addresses:

      224.0.0.10 for IPv4 "EIGRP Routers" [13]
      FF02:0:0:0:0:0:0:A for IPv6 "EIGRP Routers" [14]

   They will be used on multicast-capable media and will be media
   independent for unicast addresses.  Network-layer addresses will be
   used and the mapping to media addresses will be achieved by the
   native protocol mechanisms.

4.1.  UPDATE Packets

   UPDATE packets carry the DUAL UPDATE message type and are used to
   convey information about destinations and the reachability of those
   destinations.  When a new neighbor is discovered, unicast UPDATE
   packets are used to transmit a full table to the new neighbor, so the
   neighbor can build up its topology table.  In normal operation (other
   than neighbor startup such as a link cost changes), UPDATE packets
   are multicast.  UPDATE packets are always transmitted reliably.  Each
   TLV destination will be processed individually through the DUAL FSM.

4.2.  QUERY Packets

   A QUERY packet carries the DUAL QUERY message type and is sent by a
   router to advertise that a route is in ACTIVE state and the
   originator is requesting alternate path information from its
   neighbors.  An infinite metric is encoded by setting the delay part
   of the metric to its maximum value.

   If there is a topology change that causes multiple destinations to be
   marked ACTIVE, EIGRP will build one or more QUERY packets for all
   destinations present.  The state of each route is recorded
   individually, so a responding QUERY or REPLY need not contain all the
   same destinations in a single packet.  Since EIGRP uses a reliable
   transport mechanism, route QUERY packets are also guaranteed be
   reliably delivered.

Top      Up      ToC       Page 22 
   When a QUERY packet is received, each destination will trigger a DUAL
   event, and the state machine will run individually for each route.
   Once the entire original QUERY packet is processed, then a REPLY or
   SIA-REPLY will be sent with the latest information.

4.3.  REPLY Packets

   A REPLY packet carries the DUAL REPLY message type and will be sent
   in response to a QUERY or SIA-QUERY packet.  The REPLY packet will
   include a TLV for each destination and the associated vector metric
   in its own topology table.

   The REPLY packet is sent after the entire received QUERY packet is
   processed.  When a REPLY packet is received, there is no reason to
   process the packet before an acknowledgment is sent.  Therefore, an
   acknowledgment is sent immediately and then the packet is processed.
   The sending of the acknowledgment is accomplished either by sending
   an ACK packet or by piggybacking the acknowledgment onto another
   packet already being transmitted.

   Each TLV destination will be processed individually through the DUAL
   FSM.  When a QUERY is received for a route that doesn't exist in our
   topology table, a REPLY with an infinite metric is sent and an entry
   in the topology table is added with the metric in the QUERY if the
   metric is not an infinite value.

   If a REPLY for a designation not in the Active state, or not in the
   topology table, EIGRP will acknowledge the packet and discard the
   REPLY.

4.4.  Exception Handling

4.4.1.  Active Duration (SIA)

   When an EIGRP router transitions to ACTIVE state for a particular
   destination, a QUERY is sent to a neighbor and the ACTIVE timer is
   started to limit the amount of time a destination may remain in an
   ACTIVE state.

   A route is regarded as SIA when it does not receive a REPLY within a
   preset time.  This time interval is broken into two equal periods
   following the QUERY, and up to three additional "busy" periods in
   which an SIA-QUERY packet is sent for the destination.

   This process is begun when a router sends a QUERY to its neighbor.
   After one-half the SIA time interval (default implementation is 90
   seconds), the router will send an SIA-QUERY; this must be replied to
   with either a REPLY or SIA-REPLY.  Any neighbor that fails to send

Top      Up      ToC       Page 23 
   either a REPLY or SIA-REPLY with-in one-half the SIA interval will
   result in the neighbor being deemed to be "stuck" in the active
   state.

   Cisco also limits the number of SIA-REPLY messages allowed to three.
   Once the timeout occurs after the third SIA-REPLY with the neighbor
   remaining in an ACTIVE state (as noted in the SIA-Reply message), the
   neighbor being deemed to be "stuck" in the active state.

   If the SIA state is declared, DUAL may take one of two actions;

      a) Delete the route from that neighbor, acting as if the neighbor
         had responded with an unreachable REPLY message from the
         neighbor.

      b) Delete all routes from that neighbor and reset the adjacency
         with that neighbor, acting as if the neighbor had responded
         with an unreachable message for all routes.

   Implementation note: Cisco currently implements option (b).

4.4.1.1.  SIA-QUERY

   When a QUERY is still outstanding and awaiting a REPLY from a
   neighbor, there is insufficient information to determine why a REPLY
   has not been received.  A lost packet, congestion on the link, or a
   slow neighbor could cause a lack of REPLY from a downstream neighbor.

   In order to try to ascertain if the neighboring device is still
   attempting to converge on the active route, EIGRP may send an SIA-
   QUERY packet to the active neighbor(s).  This enables an EIGRP router
   to determine if there is a communication issue with the neighbor or
   if it is simply still attempting to converge with downstream routers.

   By sending an SIA-QUERY, the originating router may extend the
   effective active time by resetting the ACTIVE timer that has been
   previously set, thus allowing convergence to continue so long as
   neighbor devices successfully communicate that convergence is still
   underway.

   The SIA-QUERY packet SHOULD be sent on a per-destination basis at
   one-half of the ACTIVE timeout period.  Up to three SIA-QUERY packets
   for a specific destination may be sent, each at a value of one-half
   the ACTIVE time, so long as each are successfully acknowledged and
   met with an SIA-REPLY.

Top      Up      ToC       Page 24 
   Upon receipt of an SIA-QUERY packet, an EIGRP router should first
   send an ACK and then continue to process the SIA-QUERY information.
   The QUERY is sent on a per-destination basis at approximately one-
   half the active time.

   If the EIGRP router is still active for the destination specified in
   the SIA-QUERY, the router should respond to the originator with the
   SIA-REPLY indicating that active processing for this destination is
   still underway by setting the ACTIVE flag in the packet upon
   response.

   If the router receives an SIA-QUERY referencing a destination for
   which it has not received the original QUERY, the router should treat
   the packet as though it was a standard QUERY:

      1) Acknowledge the receipt of the packet

      2) Send a REPLY if a successor exists

      3) If the SIA-QUERY is from the successor, transition to the
         ACTIVE state if and only if a Feasibility Condition check fails
         and send an SIA-REPLY with the ACTIVE bit set

4.4.1.2.  SIA-REPLY

   An SIA-REPLY packet is the corresponding response upon receipt of an
   SIA-QUERY from an EIGRP neighbor.  The SIA-REPLY packet will include
   a TLV for each destination and the associated vector metric in the
   topology table.  The SIA-REPLY packet is sent after the entire
   received SIA-QUERY packet is processed.

   If the EIGRP router is still ACTIVE for a destination, the SIA-REPLY
   packet will be sent with the ACTIVE bit set.  This confirms for the
   neighbor device that the SIA-QUERY packet has been processed by DUAL
   and that the router is still attempting to resolve a loop-free path
   (likely awaiting responses to its own QUERY to downstream neighbors).

   The SIA-REPLY informs the recipient that convergence is complete or
   still ongoing; it is an explicit notification that the router is
   still actively engaged in the convergence process.  This allows the
   device that sent the SIA-QUERY to determine whether it should
   continue to allow the routes that are not converged to be in the
   ACTIVE state or if it should reset the neighbor relationship and
   flush all routes through this neighbor.

Top      Up      ToC       Page 25 
5. EIGRP Operation

   EIGRP has four basic components:

        o Finite State Machine
        o Reliable Transport Protocol
        o Neighbor Discovery/Recovery
        o Route Management

5.1.  Finite State Machine

   The detail of DUAL, the State Machine used by EIGRP, is covered in
   Section 3.5.

5.2.  Reliable Transport Protocol

   The reliable transport is responsible for guaranteed, ordered
   delivery of EIGRP packets to all neighbors.  It supports intermixed
   transmission of multicast and unicast packets.  Some EIGRP packets
   must be transmitted reliably and others need not.  For efficiency,
   reliability is provided only when necessary.

   For example, on a multi-access network that has multicast
   capabilities, such as Ethernet, it is not necessary to send HELLOs
   reliably to all neighbors individually.  EIGRP sends a single
   multicast HELLO with an indication in the packet informing the
   receivers that the packet need not be acknowledged.  Other types of
   packets, such as UPDATE packets, require acknowledgment and this is
   indicated in the packet.  The reliable transport has a provision to
   send multicast packets quickly when there are unacknowledged packets
   pending.  This helps ensure that convergence time remains low in the
   presence of varying speed links.

   DUAL assumes there is lossless communication between devices and thus
   must depend on the transport protocol to guarantee that messages are
   transmitted reliably.  EIGRP implements the reliable transport
   protocol to ensure ordered delivery and acknowledgment of any
   messages requiring reliable transmission.  State variables such as a
   received sequence number, acknowledgment number, and transmission
   queues MUST be maintained on a per-neighbor basis.

Top      Up      ToC       Page 26 
   The following sequence number rules must be met for the EIGRP
   reliable transport protocol to work correctly:

      o  A sender of a packet includes its global sequence number in the
         sequence number field of the fixed header.  The sequence number
         wraps around to one when the maximum value is exceeded
         (sequence number zero is reserved for unreliable transmission).
         The sender includes the receivers sequence number in the
         acknowledgment number field of the fixed header.

      o  Any packets that do not require acknowledgment must be sent
         with a sequence number of 0.

      o  Any packet that has an acknowledgment number of 0 indicates
         that sender is not expecting to explicitly acknowledge
         delivery.  Otherwise, it is acknowledging a single packet.

      o  Packets that are network-layer multicast must contain
         acknowledgment number of 0.

   When a router transmits a packet, it increments its sequence number
   and marks the packet as requiring acknowledgment by all neighbors on
   the interface for which the packet is sent.  When individual
   acknowledgments are unicast addressed by the receivers to the sender
   with the acknowledgment number equal to the packets sequence number,
   the sender SHALL clear the pending acknowledgment requirement for the
   packet from the respective neighbor.

   If the required acknowledgment is not received for the packet, it
   MUST be retransmitted.  Retransmissions will occur for a maximum of 5
   seconds.  This retransmission for each packet is tried 16 times,
   after which, if there is no ACK, the neighbor relationship is reset
   with the peer that didn't send the ACK.

   The protocol has no explicit windowing support.  A receiver will
   acknowledge each packet individually and will drop packets that are
   received out of order.

   Implementation note: The exception to this occurs if a duplicate
   packet is received, and the acknowledgment for the original packet
   has been scheduled for transmission, but not yet sent.  In this case,
   EIGRP will not send an acknowledgment for the duplicate packet, and
   the queued acknowledgment will acknowledge both the original and
   duplicate packet.

   Duplicate packets are also discarded upon receipt.  Acknowledgments
   are not accumulative.  Therefore, an ACK with a non-zero sequence
   number acknowledges a single packet.

Top      Up      ToC       Page 27 
   There are situations when multicast and unicast packets are
   transmitted close together on multi-access broadcast-capable
   networks.  The reliable transport mechanism MUST ensure that all
   multicasts are transmitted in order and not mix the order among
   unicast and multicast packets.  The reliable transport provides a
   mechanism to deliver multicast packets in order to some receivers
   quickly, while some receivers have not yet received all unicast or
   previously sent multicast packets.  The SEQUENCE_TYPE TLV in HELLO
   packets achieves this.  This will be explained in more detail in this
   section.

   Figure 5 illustrates the reliable transport protocol on point-to-
   point links.  There are two scenarios that may occur: an UPDATE-
   initiated packet exchange or a QUERY-initiated packet exchange.

   This example will assume no packet loss.

Router A                          Router B

                An Example UPDATE Exchange
                                 <----------------
                                 UPDATE (multicast)
A receives packet                SEQ=100, ACK=0
                                 Add packet to A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=100                   Receive ACK
Process UPDATE                   Delete packet from A's retransmit list

                An Example QUERY Exchange
                                 <----------------
                                 QUERY (multicast)
A receives packet                SEQ=101, ACK=0
Process QUERY                    Add packet to A's retransmit list

---------------->
REPLY (unicast)
SEQ=201, ACK=101                 Process ACK
                                 Delete packet from A's retransmit
list
                                 Process REPLY packet
                                 <----------------
                                 ACK (unicast)
A receives packet                SEQ=0, ACK=201

       Figure 5: Reliable Transfer on Point-to-Point Links

Top      Up      ToC       Page 28 
   The UPDATE exchange sequence requires UPDATE packets sent to be
   delivered reliably.  The UPDATE packet transmitted contains a
   sequence number that is acknowledged by a receipt of an ACK packet.
   If the UPDATE or the ACK packet is lost on the network, the UPDATE
   packet will be retransmitted.

   This example will assume there is heavy packet loss on a network.

Router A                           Router B
                                 <----------------
                                 UPDATE (multicast)
A receives packet                SEQ=100, ACK=0
                                 Add packet to A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=100                   Receive ACK
Process UPDATE                   Delete packet from A's retransmit list

                                 <--/LOST/--------------
                                 UPDATE (multicast)
                                 SEQ=101, ACK=0
                                 Add packet to A's retransmit list

                                 Retransmit Timer Expires
                                 <----------------
                                 Retransmit UPDATE (unicast)
                                 SEQ=101, ACK=0
                                 Keep packet on A's retransmit list
---------------->
ACK (unicast)
SEQ=0, ACK=101                   Receive ACK
Process UPDATE                   Delete packet from A's retransmit list

          Figure 6: Reliable Transfer on Lossy Point-to-Point Links

   Reliable delivery on multi-access LANs works in a similar fashion to
   point-to-point links.  The initial packet is always multicast and
   subsequent retransmissions are unicast addressed.  The
   acknowledgments sent are always unicast addressed.  Figure 7 shows an
   example with four routers on an Ethernet.

           Router B -----------+
                               |
           Router C -----------+------------ Router A
                               |
           Router D -----------+

Top      Up      ToC       Page 29 
                        An Example UPDATE Exchange
                                  <----------------
                                  A send UPDATE (multicast)
                                  SEQ=100, ACK=0
                                  Add packet to B's retransmit list
                                  Add packet to C's retransmit list
                                  Add packet to D's retransmit list
---------------->
B sends ACK (unicast)
SEQ=0, ACK=100                    Receive ACK
Process UPDATE                    Delete packet from B's retransmit list

---------------->
C sends ACK (unicast)
SEQ=0, ACK=100                    Receive ACK
Process UPDATE                    Delete packet from C's retransmit list

---------------->
D sends ACK (unicast)
SEQ=0, ACK=100                    Receive ACK
Process UPDATE                    Delete packet from D's retransmit list

                         An Example QUERY Exchange
                                  <----------------
                                  A sends UPDATE (multicast)
                                  SEQ=101, ACK=0
                                  Add packet to B's retransmit list
                                  Add packet to C's retransmit list
                                  Add packet to D's retransmit list

---------------->
B sends REPLY (unicast)           <----------------
SEQ=511, ACK=101                  A sends ACK (unicast to B)
Process UPDATE                    SEQ=0, ACK=511
                                  Delete packet from B's retransmit list
---------------->
C sends REPLY (unicast)           <----------------
SEQ=200, ACK=101                  A sends ACK (unicast to C)
Process UPDATE                    SEQ=0, ACK=200
                                  Delete packet from C's retransmit list

---------------->
D sends REPLY (unicast)           <----------------
SEQ=11, ACK=101                   A sends ACK (unicast to D)
Process UPDATE                    SEQ=0, ACK=11
                                  Delete packet from D's retransmit list

         Figure 7: Reliable Transfer on Multi-Access Links

Top      Up      ToC       Page 30 
   And finally, a situation where numerous multicast and unicast packets
   are sent close together in a multi-access environment is illustrated
   in Figure 8.

        Router B -----------+
                            |
        Router C -----------+------------ Router A
                            |
        Router D -----------+

                                <----------------
                                A sends UPDATE (multicast)
                                SEQ=100, ACK=0
---------------/LOST/->         Add packet to B's retransmit list
B sends ACK (unicast)           Add packet to C's retransmit list
SEQ=0, ACK=100                  Add packet to D's retransmit list

---------------->
C sends ACK (unicast)
SEQ=0, ACK=100                  Delete packet from C's retransmit list

---------------->
D sends ACK (unicast)
SEQ=0, ACK=100                  Delete packet from D's retransmit list
                                <----------------
                                A sends HELLO (multicast)
                                SEQ=0, ACK=0, SEQ_TLV listing B

B receives Hello, does not set CR-Mode
C receives Hello, sets CR-Mode
D receives Hello, sets CR-Mode

                                <----------------
                                A sends UPDATE (multicast)
                                SEQ=101, ACK=0, CR-Flag=1
---------------/LOST/->         Add packet to B's retransmit list
B sends ACK (unicast)           Add packet to C's retransmit list
SEQ=0, ACK=100                  Add packet to D's retransmit list

B ignores UPDATE 101 because the CR-Flag
is set and it is not in CR-Mode

---------------->
C sends ACK (unicast)
SEQ=0, ACK=101

Top      Up      ToC       Page 31 
---------------->
D sends ACK (unicast)

SEQ=0, ACK=101
                                <----------------
                                A resends UPDATE (unicast to B)
                                SEQ=100, ACK=0
B packet duplicate

--------------->
B sends ACK (unicast)           A removes packet from retransmit list
SEQ=0, ACK=100
                                <----------------
                                A resends UPDATE (unicast to B)
                                SEQ=101, ACK=0

--------------->
B sends ACK (unicast)            A removes packet from retransmit list
SEQ=0, ACK=101

         Figure 8: Reliable Transfer on Multi-Access Links
                      with Conditional Receive

   Initially, Router A sends a multicast addressed UPDATE packet on the
   LAN.  B and C receive it and send acknowledgments.  Router B receives
   the UPDATE, but the acknowledgment sent is lost on the network.
   Before the retransmission timer for Router B's packet expires, there
   is an event that causes a new multicast addressed UPDATE to be sent.

   Router A detects that there is at least one neighbor on the interface
   with a full queue.  Therefore, it MUST signal that neighbor not to
   receive the next packet or it would receive the retransmitted packet
   out of order.  If all neighbors on the interface have a full queue,
   then EIGRP should reschedule the transmission of the UPDATE once the
   queues are no longer full.

   Router A builds a HELLO packet with a SEQUENCE_TYPE TLV indicating
   all the neighbors that have full queues.  In this case, the only
   neighbor address in the list is Router B.  The HELLO packet is sent
   via multicast unreliably out the interface.

   Routers C and D process the SEQUENCE_TYPE TLV by looking for their
   own addresses in the list.  If not found, they put themselves in CR-
   Mode.

   Router B does not find its address in the SEQUENCE TLV peer list, so
   it enters CR-Mode.  Packets received by Router B with the CR-Flag
   MUST be discarded and not acknowledged.

Top      Up      ToC       Page 32 
   Later, Router A will unicast transmit both packets 100 and 101
   directly to Router B.  Router B already has 100, so it discards and
   acknowledges it.

   Router B then accepts and acknowledges packet 101.  Once an
   acknowledgment is received, Router A can remove both packets from
   Router B's transmission list.

5.2.1.  Bandwidth on Low-Speed Links

   By default, EIGRP limits itself to using no more than 50% of the
   bandwidth reported by an interface when determining packet-pacing
   intervals.  If the bandwidth does not match the physical bandwidth
   (the network architect may have put in an artificially low or high
   bandwidth value to influence routing decisions), EIGRP may:

      1. Generate more traffic than the interface can handle, possibly
         causing drops, thereby impairing EIGRP performance.

      2. Generate a lot of EIGRP traffic that could result in little
         bandwidth remaining for user data.  To control such
         transmissions, an interface-pacing timer is defined for the
         interfaces on which EIGRP is enabled.  When a pacing timer
         expires, a packet is transmitted out on that interface.

5.3.  Neighbor Discovery/Recovery

   Neighbor Discovery/Recovery is the process that routers use to
   dynamically learn of other routers on their directly attached
   networks.  Routers MUST also discover when their neighbors become
   unreachable or inoperative.  This process is achieved with low
   overhead by periodically sending small HELLO packets.  As long as any
   packets are received from a neighbor, the router can determine that
   neighbor is alive and functioning.  Only after a neighbor router is
   considered operational can the neighboring routers exchange routing
   information.

5.3.1.  Neighbor Hold Time

   Each router keeps state information about adjacent neighbors.  When
   newly discovered neighbors are learned the address, interface, and
   Hold Time of the neighbor is noted.  When a neighbor sends a HELLO,
   it advertises its Hold Time.  The Hold Time is the amount of time a
   router treats a neighbor as reachable and operational.  In addition
   to the HELLO packet, if any packet is received within the Hold Time
   period, then the Hold Time period will be reset.  When the Hold Time
   expires, DUAL is informed of the topology change.

Top      Up      ToC       Page 33 
5.3.2.  HELLO Packets

   When an EIGRP router is initialized, it will start sending HELLO
   packets out any interface on which EIGRP is enabled.  HELLO packets,
   when used for neighbor discovery, are normally sent multicast
   addressed.  The HELLO packet will include the configured EIGRP metric
   K-values.  Two routers become neighbors only if the K-values are the
   same.  This enforces that the metric usage is consistent throughout
   the Internet.  Also included in the HELLO packet is a Hold Time
   value.  This value indicates to all receivers the length of time in
   seconds that the neighbor is valid.  The default Hold Time will be
   three times the HELLO interval.  HELLO packets will be transmitted
   every 5 seconds (by default).  There may be a configuration command
   that controls this value and therefore changes the Hold Time.  HELLO
   packets are not transmitted reliably, so the sequence number should
   be set to 0.

5.3.3.  UPDATE Packets

   A router detects a new neighbor by receiving a HELLO packet from a
   neighbor not presently known.  To ensure unicast and multicast packet
   delivery, the detecting neighbor will send a unicast UPDATE packet to
   the new neighbor with no routing information (the NULL UPDATE
   packet).  The initial NULL UPDATE packet sent MUST have the INIT-Flag
   set and contain no topology information.

   Implementation note: The NULL UPDATE packet is used to ensure
   bidirectional UNICAST packet delivery as the NULL UPDATE and the ACK
   are both sent unicast.  Additional UPDATE packets cannot be sent
   until the initial NULL UPDATE packet is acknowledged.

   The INIT-Flag instructs the neighbor to advertise its routes, and it
   is also useful when a neighbor goes down and comes back up before the
   router detects it went down.  In this case, the neighbor needs new
   routing information.  The INIT-Flag informs the router to send it.

   Implementation note: When a router sends an UPDATE with the INIT-Flag
   set, and without the Restart (RS) flag set in the header, the
   receiving neighbor must also send an UPDATE with the INIT-Flag.
   Failure to do so will result in a Cisco device posting a "stuck in
   INIT state" error and subsequent discards.

Top      Up      ToC       Page 34 
5.3.4.  Initialization Sequence

            Router A                           Router B
          (just booted)                    (up and running)

        (1)---------------->
             HELLO (multicast)           <----------------     (2)
             SEQ=0, ACK=0                 HELLO (multicast)
                                          SEQ=0, ACK=0

                                         <----------------     (3)
                                          UPDATE (unicast)
                                          SEQ=10, ACK=0, INIT
        (4)---------------->              UPDATE 11 is queued
             UPDATE (unicast)
             SEQ=100, ACK=10, INIT       <----------------     (5)
                                         UPDATE (unicast)
                                         SEQ=11, ACK=100
                                         All UPDATES sent
        (6)--------------/lost/->
             ACK (unicast)
             SEQ=0, ACK=11
                                         (5 seconds later)
                                         <----------------     (7)
             Duplicate received,         UPDATE (unicast)
             packet discarded            SEQ=11, ACK=100
        (8)--------------->
             ACK (unicast)
             SEQ=0, ACK=11

                    Figure 9: Initialization Sequence

   (1) Router A sends a multicast HELLO and Router B discovers it.

   (2) Router B sends an expedited HELLO and starts the process of
       sending its topology table to Router A.  In addition, Router B
       sends the NULL UPDATE packet with the INIT-Flag.  The second
       packet is queued, but it cannot be sent until the first is
       acknowledged.

   (3) Router A receives the first UPDATE packet and processes it as a
       DUAL event.  If the UPDATE contains topology information, the
       packet will be processed and stored in a topology table.  Router
       B sends its first and only UPDATE packet with an accompanied ACK.

Top      Up      ToC       Page 35 
   (4) Router B receives UPDATE packet 100 from Router A.  Router B can
       dequeue packet 10 from A's transmission list since the UPDATE
       acknowledged 10.  It can now send UPDATE packet 11 and with an
       acknowledgment of Router A's UPDATE.

   (5) Router A receives the last UPDATE packet from Router B and
       acknowledges it.  The acknowledgment gets lost.

   (6) Router B later retransmits the UPDATE packet to Router A.

   (7) Router A detects the duplicate and simply acknowledges the
       packet.  Router B dequeues packet 11 from A's transmission list,
       and both routers are up and synchronized.

5.3.5.  Neighbor Formation

   To prevent packets from being sent to a neighbor prior to verifying
   multicast and unicast packet delivery is reliable, a three-way
   handshake is utilized.

   During normal adjacency formation, multicast HELLOs cause the EIGRP
   process to place new neighbors into the neighbor table.  Unicast
   packets are then used to exchange known routing information and
   complete the neighbor relationship (Section 5.2).

   To prevent EIGRP from sending sequenced packets to neighbors that
   fail to have bidirectional unicast/multicast, or one neighbor
   restarts while building the relationship, EIGRP MUST place the newly
   discovered neighbor in a "pending" state as follows:

      when Router A receives the first multicast HELLO from Router B, it
      places Router B in the pending state and transmits a unicast
      UPDATE containing no topology information and SHALL set the
      initialization bit.  While Router B is in this state, A will send
      it neither a QUERY nor an UPDATE.  When Router A receives the
      unicast acknowledgment from Router B, it will change the state
      from "pending" to "up".

5.3.6.  QUERY Packets during Neighbor Formation

   As described above, during the initial formation of the neighbor
   relationship, EIGRP uses a form of three-way handshake to verify both
   unicast and multicast connectivity are working successfully.  During
   this period of neighbor creation, the new neighbor is considered to
   be in the pending state, and it is not eligible to be included in the
   convergence process.

Top      Up      ToC       Page 36 
   Because of this, any QUERY received by an EIGRP router would not
   cause a QUERY to be sent to the new (and pending) neighbor.  It would
   perform the DUAL process without the new peer in the conversation.
   To do this, when a router in the process of establishing a new
   neighbor receives a QUERY from a fully established neighbor, it
   performs the normal DUAL Feasible Successor check to determine
   whether it needs to REPLY with a valid path or whether it needs to
   enter the ACTIVE process on the prefix.

   If it determines that it must go active, each fully established
   neighbor that participates in the convergence process will be sent a
   QUERY packet, and REPLY packets are expected from each.  Any pending
   neighbor will not be expected to REPLY and will not be sent a QUERY
   directly.  If it resides on an interface containing a mix of fully
   established neighbors and pending neighbors, it might receive the
   QUERY, but it will not be expected to REPLY to it.

5.4.  Topology Table

   The topology table is populated by the Protocol-Dependent Modules
   (PDMs) (IPv4/IPv6), and it is acted upon by the DUAL finite state
   machine.  Associated with each entry are the destination address, a
   list of neighbors that have advertised this destination, and the
   metric associated with the destination.  The metric is referred to as
   the "CD".

   The CD is the best-advertised RD from all neighbors, plus the link
   cost between the receiving router and the neighbor.

   The "RD" is the CD as advertised by the Feasible Successor for the
   destination.  In other words, the Computed Distance, when sent by a
   neighbor, is referred to as the "Reported Distance" and is the metric
   that the neighboring router uses to reach the destination (its CD as
   described above).

   If the router is advertising a destination route, it MUST be using
   the route to forward packets; this is an important rule that distance
   vector protocols MUST follow.

5.4.1.  Route Management

   Within the topology table, EIGRP has the notion of internal and
   external routes.  Internal routes MUST be preferred over external
   routes, independent of the metric.  In practical terms, if an
   internal route is received, the diffusing computation will be run
   considering only the internal routes.  Only when no internal routes
   for a given destination exist will EIGRP choose the successor from
   the available external routes.

Top      Up      ToC       Page 37 
5.4.1.1.  Internal Routes

   Internal routes are destinations that have been originated within the
   same EIGRP AS.  Therefore, a directly attached network that is
   configured to run EIGRP is considered an internal route and is
   propagated with this information throughout the network topology.

   Internal routes are tagged with the following information:

      o Router ID of the EIGRP router that originated the route.
      o Configurable administrator tag.

5.4.1.2.  External Routes

   External routes are destinations that have been learned from another
   source, such as a different routing protocol or static route.  These
   routes are marked individually with the identity of their
   origination.  External routes are tagged with the following
   information:

      o Router ID of the EIGRP router that redistributed the route.
      o AS number where the destination resides.
      o Configurable administrator tag.
      o Protocol ID of the external protocol.
      o Metric from the external protocol.
      o Bit flags for default routing.

   As an example, suppose there is an AS with three border routers: BR1,
   BR2, and BR3.  A border router is one that runs more than one routing
   protocol.  The AS uses EIGRP as the routing protocol.  Two of the
   border routers, BR1 and BR2, also use Open Shortest Path First (OSPF)
   [10] and the other, BR3, also uses the Routing Information Protocol
   (RIP).

   Routes learned by one of the OSPF border routers, BR1, can be
   conditionally redistributed into EIGRP.  This means that EIGRP
   running in BR1 advertises the OSPF routes within its own AS.  When it
   does so, it advertises the route and tags it as an OSPF-learned route
   with a metric equal to the routing table metric of the OSPF route.
   The router-id is set to BR1.  The EIGRP route propagates to the other
   border routers.

   Let's say that BR3, the RIP border router, also advertises the same
   destinations as BR1.  Therefore, BR3, redistributes the RIP routes
   into the EIGRP AS.  BR2, then, has enough information to determine
   the AS entry point for the route, the original routing protocol used,
   and the metric.

Top      Up      ToC       Page 38 
   Further, the network administrator could assign tag values to
   specific destinations when redistributing the route.  BR2 can utilize
   any of this information to use the route or re-advertise it back out
   into OSPF.

   Using EIGRP route tagging can give a network administrator flexible
   policy controls and help customize routing.  Route tagging is
   particularly useful in transit ASes where EIGRP would typically
   interact with an inter-domain routing protocol that implements global
   policies.

5.4.2.  Split Horizon and Poison Reverse

   In some circumstances, EIGRP will suppress or poison QUERY and UPDATE
   information to prevent routing loops as changes propagate though the
   network.

   Within Cisco, the split horizon rule suggests: "Never advertise a
   route out of the interface through which it was learned".  EIGRP
   implements this to mean, "if you have a successor route to a
   destination, never advertise the route out the interface on which it
   was learned".

   The poison reverse rule states: "A route learned through an interface
   will be advertised as unreachable through that same interface".  As
   with the case of split horizon, EIGRP applies this rule only to
   interfaces it is using for reaching the destination.  Routes learned
   though interfaces that EIGRP is NOT using to reach the destination
   may have the route advertised out those interfaces.

   In EIGRP, split horizon suppresses a QUERY, where as poison reverse
   advertises a destination as unreachable.  This can occur for a
   destination under any of the following conditions:

      o two routers are in startup or restart mode
      o advertising a topology table change
      o sending a query

5.4.2.1.  Startup Mode

   When two routers first become neighbors, they exchange topology
   tables during startup mode.  For each destination a router receives
   during startup mode, it advertises the same destination back to its
   new neighbor with a maximum metric (Poison Route).

Top      Up      ToC       Page 39 
5.4.2.2.  Advertising Topology Table Change

   If a router uses a neighbor as the successor for a given destination,
   it will send an UPDATE for the destination with a metric of infinity.

5.4.2.3.  Sending a QUERY/UPDATE

   In most cases, EIGRP follows normal split-horizon rules.  When a
   metric change is received from the successor via QUERY or UPDATE that
   causes the route to go ACTIVE, the router will send a QUERY to
   neighbors on all interfaces except the interface toward the
   successor.

   In other words, the router does not send the QUERY out of the inbound
   interface through which the information causing the route to go
   ACTIVE was received.

   An exception to this can occur if a router receives a QUERY from its
   successor while already reacting to an event that did not cause it to
   go ACTIVE, for example, a metric change from the successor that did
   not cause an ACTIVE transition, but was followed by the UPDATE/QUERY
   that does result the router to transition to ACTIVE.



(page 39 continued on part 3)

Next RFC Part