RFC 7868
Cisco's Enhanced Interior Gateway Routing Protocol (EIGRP)
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.
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.
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
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.
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.
5. EIGRP Operation
EIGRP has four basic components: o Finite State Machine o Reliable Transport Protocol o Neighbor Discovery/Recovery o Route Management5.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.
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.
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
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 -----------+
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
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
----------------> 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.
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.
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.
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.
(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.
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.
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.
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 query5.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).
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)
