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: 224.0.0.10
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?
Authentication
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)
Passive/Active:
- 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”
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?