EIGRP quick ref

Hello Time

  • Generally: every 5 seconds
  • Multipoint WAN /w BW < 1544Kbps (F/R ATM & X.25): every 60 seconds (unicast)
  • Not sent ‘via’ secondary addresses!

* A number of places state 1544Mbps, though I personally do not consider that a slow WAN link. Hence my statement of 1544Kbps (= T1), I’m appalled to see so many references to the error once made by Cisco and never corrected.

Hold Time: 3x Hello time (default is 15 or 180 {MP WAN} secconds)

Multicast flow timer: Timeout of ‘Multicast update ack’

‘Loop prevention’: RD must be smaller then FD

IP protocol: 88

Multicast address:

Transport protocol: RTP (hence the term reliable multicast)

CR-mode: Conditional Receive (= unicast), used when multicast has failed (no Ack received)

Reliable transmission & packet types

  • Update: (1) yes – multicast (unicast Updates are sent to a new neighbor so it can build its topology table)
  • Query: (3) yes – multicast unless it’s in reply to another Query (destination goes into Active state)
  • Reply: (4) yes – unicast (destination goes into Active state)
  • Hello: (5) unreliable – multicast (discovery/recovery)
  • Ack: (5) unreliable – unicast (Hello /w non-zero ack number)

(*) = opcode (2nd byte in EIGRP packet)
Ack is not needed on a multiaccess network (unreliable multicast)
An unicast Hello without data is used as an Ack for Updates
Init flag: Indicates that the the route entries in the Update packet are the first in a new neighborship relationship
For routing protocol traffic to pass over an ISDN link the broadcast keyword must be present in the dialer map (isn’t this off-topic now that dialup has been removed from CCIE R&S per 1 jan 2006?)

Whatever happened to packet type #2?


  • Simple passwords [Nov 7th 2008] Just got a comment from Wil (see below) it’s not available, my memory is not that good so can’t say for sure whether I was just plainly wrong or whether Cisco removed ‘simple password’ auth…
  • MD5

DUAL (Diffusing Update ALgorithm)

  • Successor: best path
  • Feasible Successor: 2nd best path
  • Feasible Distance: lowest calculated metric (path to destination)

Feasible Distance (FD): The lowest calculated metric to a destination

Reported Distance (RD): The metric to a destination reported by a neighbor

Feasibility Condition: a condition that is met if a neighbor’s advertised distance to a destination is lower than the the router’s Feasible Distance (FD) to that same destination

Metric calculation

  • Default: BW & delay only { (10^7 / lowest bandwidth in path in Kbps) + (total path delay in usec / 10) } * 256
  • Official: {k1 * BW + [(k2 * BW) / (256 – load)] + k3 * delay} * {k5 / (reliability + k4)}
  • k1: bandwidth
  • k2: bandwidth / load
  • k3: delay
  • k4: – reliability
  • k5: + reliability

A delay of FFFFFFFF (all 1s) means unreachable
Reliability and load are both fractions of 255, 255 being 100%
Ethernet is typically 10Mbps with a delay of 1msec, resulting an EIGRP metric of (1000+100)*256=281600

The ‘k’ values are configured with the following line: (config-router)#metric weights 0 1 1 1 1 1 (tos) (k1)…k5). Tos is never used and thus always 0. (1=on & 0=off)

  • P: no recomputations going on
  • A: EIGRP is using DUAL to recompute the route (network in transition)

Variance command: enables unequal loadbalancing

Administrative distance:

  • EIGRP summary: 5
  • EIGRP: 90
  • EIGRP external: 170

All external routes (different major network or external) will be summarised to their classfull boundaries per default. And the summarising router will install a Null0 route for the summarised address.

The interface summary command derives the summary metric from the route that has the smallest (best) metric

(config-router)#eigrp stub ?

  • connected – Do advertise connected routes
  • receive-only – Set IP-EIGRP as receive only neighbor
  • static – Do advertise static routes
  • summary – Do advertise summary routes

To be configured on the stub router
The default is connected and summary routes (ie not redistributed static routes)
The receive-only keyword will not permit any other option to be specified because it prevents any type of route from being sent

One Response to “EIGRP quick ref”

Wil wrote a comment on 6 Nov 2008

Hello. First let me say, nice site. Secondly, I believe you may have a mistake here. You say that for EIGRP Packet Authentication you can use simple or MD5 when in fact, EIGRP only supports MD5 authentication. I am stating this based on what my CCIE book says and several other sources. Just letting you know, not trying to be @ss. I labbed it up just to verify and here is my result in case you are interested.

Router1(config-if)#ip authentication mode eigrp 1 ?
md5 Keyed message digest

Care to comment?