Quick Notes: EIGRP Packes, EIGRP Neighbors (CCIE Official Cert Guide: Chapter 8)

From: CCIE Routing and Switching v5.0 Official Cert Guide, Volume 1, 5th Edition


EIGRP Packet Format

  • Carried directly in IP packets, using protcol number 88.
  • The maximum length of an EIGRP packet is derived from the maximum IP MTU on the particular interface - typically 1500 bytes for the entire IP packet, leaving 1480 bytes for the EIGRP packet itself.
  • Each EIGRP packet carries a 20-byte header, followed by a variably sized body (TLVs).
  • There is no clearly delineated RTP header.
  • Instead, the Flags, Sequence Number, and Acknowledgement number fields provide most of the RTP functionality (also specific TLVs).


  • Version: 4-bit field used to indicate the protocol version of the originating EIGRP process. Has not changed since its release and is set to 2.
  • Opcode: 4-bit field that specifies the EIGRP packet type. 1 = Update, 3 = Query, 4 = Reply, 5 = Hello/Ack, 10 = SIA-Query, 11 = SIA-Reply.
  • Checksum: 24-bit field used to run a sanity check on the EIGRP packet, excluding the IP header.
  • Flags: 32-bit field indicating specific flags. 0x1 = Init (used during initial adjacency buildup), 0x2 = Conditional Receive (used by RTP to allow this message to be received only by a subset of receivers), 0x4 = Restart (indicates that a router has restarted), 0x8 = End-of-Table (indicates that the transmission of the entire EIGRP database is complete).
  • Sequence: 32-bit field that contains a sequence number used by RTP for orderly delivery of reliable packets.
  • Acknowledgement: 32-bit field used by RTP that contains the sequence number of the last packet heard from the neighbor. A Hello packet with a non-zero ACK field is an ACK rather than a Hello. Acknowledgements are never multicasted.
  • Virtual Router ID: 16-bit field identifying the virtual router this packet is associated with. 0x1 = Unicast Address Family, 0x2 = Multicast Address Family, 0x8000 = Unicast Service Address Family.
  • Autonomous System Number: 16-bit field that identifies the number of the EIGRP domain.
  • Type-Length-Value: Field used to carry route entries as well as provide EIGRP DUAL information. Several different types: 
    • 0x0001 EIGRP Parameters ( General TLV Types )
    • 0x0002 Authentication Type ( General TLV Types )
    • 0x0003 Sequence ( General TLV Types )
    • 0x0004 Software Version ( General TLV Types )
    • 0x0005 Next Multicast Sequence ( General TLV Types ) 
    • 0x0102 IPv4 Internal Routes ( IP-Specific TLV Types )
    • 0x0103 IPv4 External Routes ( IP-Specific TLV Types )
    • 0x0402 IPv6 Internal Routes ( IP-Specific TLV Types )
    • 0x0403 IPv6 External Routes ( IP-Specific TLV Types )
    • 0x0602 Multi Protocol Internal Routes ( AFI-Specific TLV Types )
    • 0x0603 Multi Protocol External Routes ( AFI-Specific TLV Types )


EIGRP Packets

  • EIGRP uses seven different packet types:
  1. Hello
  2. Acknowledgement
  3. Update (RTP) 
  4. Query (RTP)
  5. Reply (RTP)
  6. SIA-Query (RTP)
  7. SIA-Reply (RTP)
  • The RTP marked packets are also called reliable packets because EIGRP makes sure that they are all reliably delivered and in proper order.
  • Statistics about all sent and received EIGRP packets can be obtained using the show ip eigrp traffic command.

Hello

  • Periodic Hellos sent once EIGRP is enabled on an interface.
  • Used to identify neighbors, verify compatible configuration (common IP subnet, the same AS number, K values, and optional authentication), and serve as a keepalive mechanism between neighbors.
  • Sent to 224.0.0.10 in IPv4, and FF02::A in IPv6.
  • If static neighbors are configured, Hello packets are sent as unicasts to the neighbors explicitly configured address.
  • The default Hello interval is 5 seconds.
  • On NBMA with 1544 kbps or less, the default Hello interval is 60 seconds.
  • Opcode of 5, and not acknowledged.

Acknowledgement

  • ACK packet is used to acknowledge selected received EIGRP packets to facilitate their reliable delivery.
  • Sent in response to Update, Query, Reply, SIA-Query, and SIA-Reply.
  • Unicasted to the sender of the acknowledged packet.
  • ACK is essentially a Hello packet with an empty body (no TLVs), and having a non-zero Acknowledgement number field who value is set to the Sequence number of the reliable packet being acknowledged.
  • The same Opcode as the Hello packet, i.e. 5.
  • If both an ACK and a reliable packet are waiting to be sent to the same neighbor, EIGRP can put the acknowledgment number into the reliable packet’s Acknowledgment number field, saving the need to send a standalone ACK.
  • Only unicast packets can also be used to carry acknowledgement numbers.

Update

  • Contains routing information updates and is used to convey the reachability of destinations.
  • Can be both unicasted and multicasted.
  • Rules:
  1. During a new adjacency buildup, Update packets are unicasted between the newly discovered neighbors. In specific cases, like DMVPN, EIGRP might choose to synchronize neighbors using multicasts. The choice only impacts the efficiency of the initial synchronization process, and has no influence on the actual contents of exchanged information.
  2. After routers have fully synchronized, further Updates are sent as multicasts.
  3. If a neighbor does not acknowledge the arrival of an Update packet, EIGRP will retransmit the Update as unicast to the unresponsive neighbor.
  4. On point-to-point interfaces and for statically configured neighbors, EIGRP always uses unicast.
  • Delivered reliably; always acknowledged and retransmitted if no acknowledgement is heard.
  • Opcode of 1.

Query

  • Used to involve neighbors in the task of searching for the best route toward a destination.
  • Delivered reliably.
  • Both unicasted and multicasted.
  • By default, on multiaccess interfaces with only dynamic neighbors, Queries are sent as multicasts.
  • If not acknowledged in proper time, a Query is retransmitted to the unresponsive neighbor as unicast.
  • On point-to-point interfaces and toward statically configured neighbors, Queries are always sent as unicasts.
  • While each received Query must be acknowledged with an ACK, this ACk does not constitute a response to the Query message, only an acknowledgement that the Query has been received.
  • The Reply is used for that purpose.
  • Opcode of 3.

Reply

  • Sent in response to Query packets and carry their sender's current distance to the destination after taking into account the topology change that prompted the Query.
  • Always unicasted to the originator of the Query message, and delivered reliably.
  • Opcode of 4.

SIA-Query and SIA-Reply

  • Used during a prolonged diffusing computation to verify whether a neighbor that has not yet sent a Reply to a Query is truly reachable and still engaged in the corresponding diffusing computation.
  • The SIA-Query is used to ask a neighbor to confirm that it is still working on the original Query.
  • If the neighbor is reachable and still engaged in the diffusing computation, it will immediately respond with an SIA-Reply.
  • The maximum diffusing computation timer is reset.
  • Both SIA-Query and SIA-Reply are unicast, and reliably delivered.
  • SIA-Query uses an Opcode of 10.
  • SIA-Reply uses an Opcode of 11.

Reliable Transport Protocol

  • Manages the delivery and reception of EIGRP packets.
  • Reliably delivered packets: Update, Query, Reply, SIA-Query, and SIA-Reply (both unicast and multicast).
  • A non-zero Sequence number is carried in the packet header.
  • The Sequence number is a global value maintained per each EIGRP process instance on a router and is incremented whenever one of these packets is originated by the instance, regardless of which EIGRP-enabled interface the packet is going to be sent from.
  • Hello and ACK packets (non-reliable) set their Sequence number to zero and do not cause the global Sequence number to increase.
  • Conditional Receive: EIGRP partitions its neighbors into two groups: 1) well-behaved neighbors that have been able to acknowledge all multicast messages sent so far, and 2) "lagging" routers that have failed to acknowledge at least one EIGRP packet.
  • For in-parallel operation, EIGRP has to send the in-order multicast packets with a special flag saying "this packet is only for those routers who have received all multicast packets so far".
  • Sequenced Hello with two specific TLVs: the Sequence TLV and the Next Multicast Sequence TLV.
  • The Next Multicast Sequence TLV contains the upcoming sequence number of the next reliable multicasted message.
  • The Sequence TLV contains a list of all lagging neighbors by their IP address, in effect saying "whoever finds himself in this list, ignore the next multicast message with the indicated sequence number".
  • A neighbor receiving the Sequenced Hello and not finding itself in the Sequence TLV will know that it is expected to receive the upcoming multicast packet, and will put itself into a so-called Conditional Receive mode (CR-mode).
  • The next multicast packet is sent with the CR flag set.
  • Routers in CR-mode will process this packet as usual and then exit the CR-mode; other routers will ignore it.
  • As a result, the router is able to continue using multicast with those routers that have no issues receiving and acknowledging it, while making sure that the lagging neighbors won't process the multicasts until they are able to cacth up.
  • The time to wait for an ACK before declaring a neighbor as lagging and switching from multicast to unicast is specified by the multicast flow timer.
  • The time between the subsequent unicasts is specified by the retransmission timeout (RTO).
  • Both the multicast flow timer and the RTO are calculated for each neighbor from the smooth round-trip time (SRTT).
  • The SRTT is the average elapsed time in milliseconds between the transmission of a reliable packet to the neighbor and the receipt of an acknowledgement.

Router Adjacencies

  • EIGRP routers establish and maintain neighbor adjacencies.
  • By default, EIGRP discovers neighbors dynamically but neighbors can also be manually defined.
  • Dynamic neighbor discovery is performed by sending EIGRP Hellos to 224.0.0.10 or FF02::A as soon as as EIGRP is activated on an interface.
  • Static neighbors are typically deployed across media that does not natively support broadcast or multicast packets, such as Frame Relay.
  • After a static neighbor is defined, all EIGRP multicasts on the interface, through which the neighbor is reachable, will be disabled.
  • EIGRP neighbors must agree on the following parameters:
  1. EIGRP authentication parameters (if configured)
  2. EIGRP K values
  3. EIGRP Autonomous System (AS) number
  4. use of primary addresses for EIGRP neighbor relationships
  5. use of the common IP network address on a single subnet
  • If two routers differ in any of these parameters, they will not become EIGRP neighbors.
  • The Hello and Hold timers do not need to match between the neighbors.
  • The Hold time is the maximum time a router should wait to receive subsequent valid EIGRP packets from a neighbor.
  • If the Hold timer expires, the neighbor is declared unreachable and DUAL is informed.
  • By default, the Hold time is three times the Hello time, equaling either 15 or 180 seconds, depending on the interface type.
  • Changing the Hello interval does not result in automatic recalculation of the Hold time.
  • The timers can be changed at the interface level: ip hello-interval eigrp as-num sec and ip hold-time eigrp as-num sec.

EIGRP Neighbor Table

  • Records information about each detected neighbor with whom this router has established an adjacency.
  • The H (Handle) number is used to internally identify neighbors in an address-family independent way.
  • The Address and Interface columns hold the neighbor's IP address and this router's interface toward the neighbor.
  • The Hold time is derived from the value advertised by the neighbor and decremented each second; reset every time an acceptable EIGRP packet from that neighbor is received.
  • The Uptime shows the time the neighbor has been up.
  • The SRRT estimates the turnover time between sending a reliable packet to the neighbor and receiving an appropriate acknowledgement.
  • The RTO is the time that the router will wait for an acknowledgement of a retransmitted unicast packet before sending another copy.
  • SRRT and RTO are shown in milliseconds.
  • The Q Cnt indicates the number of enqueued reliable packets for which no ACK has been received yet.
  • In a stable network, the Q Cnt value must be zero.
  • Non-zero values are normal during initial router database synchronization or during network convergence.
  • The Sequence number shows the sequence number of the last reliable packet received from a neighbor.
  • The Sequence number is a per-process variable.
  • It is normal to see the sequence number increase by more than 1, as long as the value is ascending.

Comments