CCIE - EI: 1.3 EIGRP 📝

2022-04-29 · Topic: CCIE-EI

This is a summary of the notes I’ve written for CCIE-EI - CCIE - EI: 1.3 EIGRP. In other words, this only contains what I felt the need to write down and is not meant as a complete study resource. Please see the study resources I’ve used or related blogs for more coherent writeups.

1.3 - EIGRP

AD 90(internal), 170(external)

Transport: IP/88 -> 224.0.0.10/FF02::A

Timers: 5/15, 60/180(sub 1544kbps nbma)

ip hello-time eigrp {asn} {seconds}
ip hold-time eigrp {asn} {seconds}
eigrp> timers active-time {minutes}

Authentication: MD5 and SHA

Only MD5 is supported in classic configuration. Usually configured with a key-ring, though SHA allows for configuration directly under af-interface. Only configurable per-interface(including default interface)

! Classic
int> ip authetnciation mode eigrp {md5|hmac-sha-256 {pass}}
int> ip authetnciation key-chain eigrp {name} 

! Named 
eigrp-af-int> authentication mode {md5|hmac-sha-256 {pass}}
eigrp-af-int> authentication key-chain {name}

Roll-over is controlled by the send-lifetime and accept-lifetime specified on the key in the keychain. When multiple keys are elegible the lowest key-id will be used when sending, inbound packets indicate which key is uses and will dictate which key is used ot authenticate them.

1.3.a Adjacencies

States

  • Pending, hello packet received
  • Up, Null update(init flag, seq) sent, received and acked

Requirements

  • ASN
  • K-Values
  • Authentication
  • Primary addresses
  • Common subnet

It is important to note that the timers don’t have to match.

EIGRP will perform dynamic neighbor discovery on all eigrp enabled interfaces. The exception is when an interface is attached to a statically configured neighbor. When the static neighbor is configured the router will stop sending multicasted hello packets.

Neighbors can be viewed with show ip eigrp negihbors [ip] The ‘Q CNT’ value shows how many reliable packets that are queued, this value should be zero outside of initial database sync.

1.3.b Best path selection

metric maximum-hops {} 100 default

EIGRP has both internal and external routes, where internal routes are injected with the network command and external routes are redistributed into EIGRP.

RD, FD, FC, successor, feasible successor

  • CD = Computed Distance, before the slash
  • RD = Reported Distance, after the slash
  • FD = Feasable Distance, lowest distance since last transition to passive state
  • FC = Fasability condition, RD must be lower than current FD.
  • Successor = Router satisfying the FC and providing best RD
  • Feasible Successor = Router satisfying the FC

The feasible successor isn’t always the one to replace the successor. Upon receiving new topology information the following happens:

  1. The change in metric is recorded
  2. The best CD is chosen
  3. The best CD is checked against the FC, either updating the route or going active

Classic Metrics and Wide Metrics

Classic metrics

EIGRP Classic metrics has legacy component-metrics carried over from IGMP to ensure a smooth transition. Otherwise known as kicking the rock further down the road.

Metric components:

  • Bandwidth, minimal bandwidth along path (enabled by default)
    • Set to value of the bandwidth interface command or equal to interface speed.
    • Capable of representing speeds between 1kbps and 10Gbps.
  • Delay, cumulative along path (enabled by default)
    • Can be configured with delay interface command in tens of μs
    • Considered the best value to modify to alter routing.
    • Used in split-horizon, route poisoning, stub advertisements etc.
  • Reliability, minimal reliability along path
    • Change of value does not trigger advertisements, is static between updates.
  • Load, maximal TX load
    • Change of load does not trigger advertisement
  • MTU, sent in updates but never used
  • Hop count, only implemented as maximum TTL of a route to prevent loops
    • Configured with metric maxiumu-hops {} under EIGRP
    • Only locally significant

The composite metric is calculated by each router. In other words, each of the metric components are included in EIGRP update packets, note that both the delay and bandwidth is sent in scaled form. Each component metric must hence also be specified for redistributed routes.

K-Values are used in composite metric calculation in EIGRP. Each value can be set between 0-255, with the default being 1 0 1 0 0 in classic metrics. The K-Values must match between all routers for adjacency to come up.

Formula for classic composite metric: $$CM = [(k_1 \times Bandwidth + \frac{K_2 \times Bandwidth}{256 - Load} + (K_3 \times Delay)) \times \frac{K_5}{K_4 + Relyability}] \times 256$$

Wide metrics

Wide metrics became necessary to introduce due to higher link-speeds, lack of flexibility in setting delay and loss of precision due to scaling of bandwidth and delay component metrics. Wide metricsis supported “everywhere” but can be confirmed through checking for the K6 value in show ip protocls.

Wide metrics are used whenever named configuration is used and all neighbors support it. There is no way to explicitly configure for the use of wide metrics. EIGRP routers will send both if there’s a mix of wide-metric capable and non-wide-metric capable neighbors.

The composite wide metric is downscaled to fit within the RIB. This is achieved by dividing the composite metric with the value of metric rib-scale(128 default).

Metric components:

  • Throughput, equivalent to bandwidth.
    • Calculated as 65536*10^7/bandwidth, meaning that throughput compares speed to a 655,36Tbps link
  • Latency, eqivalent to delay.
    • Calculated as 65536*int-delay/10^6 with interface delay in picoseconds on sub Gbps interfaces and on interfaces with explicit bandwidth
    • Calculated as 10^13/interface-bandwidth on interfaces without bandwidth and delay configured.
    • Calculated as 65536configured-delay10^7/10^6 on interfaces with explicit delay
  • Reliability, same as classic metrics
  • Load, same as classic metrics
  • MTU, same as classic metrics
  • Hop count, same as classic metrics
  • Extended metrics, reserved for future use

Formula for wide metric composite metric

$$WM = [(k_1 \times Throughput + \frac{K_2 \times Throughput}{256 - Load} + (K_3 \times Latency) + (K_6 \times Extended)) \times \frac{K_5}{K_4 + Reliability }] \times 256 $$

1.3.c Operations

General operations

The Diffusing Update Algorithm(DUAL) Finite state machine handles the diffusing process. Changes of topoligy that can be resolved without querying others is called a local computation.

The EIGRP RID serves the purpose of loop prevention. It is assigned the same way as in OSPF and can differ across different address families. Any received update with a RID matching the local RID will be dropped. Changing the RID will cause all neighbor adjacencies to restart.

no next-hop-self allows an EIGRP router to not impose itself as the next hop when advertising a route, as long as the next-hop is reachable on the interface. The no-ecmp-mode optional paramater forces EIGRP to walk over all equal cost routes to ensure that the no next-hop-self is honored

Passive interfaces will not form adjacencies but still add the associated prefix to the topology table.

EIGRP doesn’t have a specific command fo rinjecting a default route. It either must be redistributed or summarized. If a static default route is configured with an outbound interface it is considered connected and can be injected with network 0.0.0.0, this is however not recommended.

EIGRP over the top EIGRP OTP allows maintaining router adjacencies across a SP network without exchanging routing information with the service provider. This is achieved through sending the EIGRP packets through a LISP overlay.

! Required non-default config
int lisp0
eigrp> neighbor {IP} {int} remote {} lisp-encap

Conditional receive

When slow neighbors are detected they are put into conditional receive mode to avoid slowing down all routers. This is achieved through sending a hello packet with the slow routers IP specified in the Sequence TLV. All routers not in the Sequence TLV enable CR mode and will continue to process multicast updates with the CR flag set. The slow routers receive the missing updates sequentially over unicast afterwards.

Topology table

Contains all EIGRP routing information.

Prefixes enter active state when there isn’t a guaranteed loop-free path based on known information(Feasability condition is no longer met). The prefixes cannot be removed from the topoligy table or change next-hop while the prefix is in the ‘active’ state.

The topology table can be examined with the following commands:

show ip eigrp topology [all-links]
show ip eigrp topology {prefix}

Packet types

EIGRP packet types:

  • Hello, 5
  • Ack, 5
  • Update*, 1
  • Query*, 3
  • Reply*, 4
  • SIA-Query*, 10
  • SIA-Reply*, 11

* = Reliable

The ACK packet is actually a regular hello packet with the ACK field populated. EIGRP allows using any unicast reliable packet to ACK a previous message.

Update packets are both unicasted and multicasted depending on the situation. During device bring-up the routers will unicast to eachother unless there are multiple neighbors on an interface. Statically configured neighbors will always receive unicasted updates and neighbors that don’t ack an update will receive a unicast update. Outside of this the updates will be multicasted.

All EIGRP messages has a 20B header followed with a varying length of TLVs containing various information.

The header fields of EIGRP packets are:

  • Version, always 2
  • Opcode, message type
  • Checksum, 24b
  • Flags, Can be set to init, CR, restart or end-of-table
  • Sequence,
  • Ack,
  • RID,
  • ASN,

show ip eigrp traffic shows stats about sent/received EIGRP packets.

Stuck In Active

Once a route goes active the router sends multicasts a query for the relevant prefix. Downstream routers will immediately ACK the query and query their neighbors for the prefix unless they have a valid loop free route. The reply messages aren’t sent until each router has received all replies to their query. Once all the replies have been received the local router will install the best learned route, ignoring the FC requirement.

When the network is very large without the necessary limits to query-scope, or a downstream router is incapable of replying the route will become “stuck in active”. Once half of the 180s active timer has passed the router will send SIA-Queries, checking whether it’s neighbors are working or crashed. If it receives a SIA-Reply IT will repeat this up to 3 times

DUAL-FSM States:

  • A0: Local Origin with Distance Increase
    • Second topology change detected while in A1
  • A1: Local Origin
    • Any other reason than query received from successor
  • A2: Multiple Origins
    • Second topology change detected while in A3
  • A3: Successor Origin
    • Query recieved from successor and FC fails

A0 and A2 requires the route to be checked against the initial FD when all replies are received. If it does not pass the additional check it will enter A1 or A3 and start another diffusing computation.

Graceful shutdown

Graceful shutdown allows EIGRP routers to notify neighbors of a shutdown by sending a goodbye message(hello with all 255 k-values). This allows neighbors to skip waiting for the hold timer.

Classic configuration only allows explicit shutdown command for IPv6. Named configuration allows the shutdown command under the eigrp process, an address family or under af-interface configuration.

1.3.d EIGRP load-balancing

Equal-cost

Requires multiple equal CDs for a specific prefix. By default 4 routes can be installed in the rib, but can be increased to 8 with max-paths.

Unequal-cost

Unequal-cost loadbalancing requires multiple routes to pass the FC, max-paths to be set and have a CD that is better than: successor CD * variance. Unequal-cost load balancing will weight the loadbalcing according to FS CD/Worst FS CD.

Add-path

Advertise up to 4 ECMP routes out an interface with the add-paths {1-4} interface commmand. UECMP must be disabled when using with add-paths.

1.3.e EIGRP Named Mode

Unified and preferred way of configuring EIRGP. Multiple named mode virtual instances can be started on a router. Each virtual instance can have one instance of each address-family. The ASN doesn’t have to match within a virtual instance, but the ASN - AF combination must be unique.

NOTE: All IPv6 interfaces will be enabled if an IPv6 address family is configured.

router eigrp {name}
eigrp> address-family {ipv4|ipv6} unicast autonomous-system {n}
eigrp-af> ... ! Process specific commands
eigrp-af> af-interface {default | {int}}
eigrp-af-int> ... ! Interface specific commands
eigrp-af> topology base
eigrp-af-topo> ... ! Routing specific commands

! New fangled show commands
show eigrp address-family {} ... 

1.3.f Optimization, convergence and scalability

Fast convergence requirements

Query propagation boundaries

Summary routing

Routers will imeediately send a reply when receiving a query for a prefix it doesn’t know. Hence routers neighboring a router performing a summary will not know the component route being queried for, and will hence not propagate the queries further.

This limits the query scope “outside -> in”, “in -> out” still follows the regular query rules.

EIGRP summary routes have an AD of 5 and is configured with ip summary-address eigrp {asn} {prefix} {mask} [distance] [leak-map {}]. The summary route will adopt the lowest component route metric and update whenever it changes, this can be made static with the summary-metric command.

EIGRP Stub

Covered below…

IP FRR (single hop)

LFA - Loop-Free Alternative FRR - Fast-Reroute

FRR allows EIGRP to install a LFA/backup path to the rib in a few milliseconds. The LFAs can be calculated per-link or per-prefix, the difference is that per-link is lighter on the resources whikle per-prefix gives better load-balancing.

The “best” LFA is chosen by the following tie-breakers

  • Interface disjoint, avoid using the same interface
  • Line-card disjoing, avoid using the same linecard
  • Lowest metric,
  • Shared Risk Link Group, administratively grouped

Shared Risk Link Groups are groups of interfaces with similar characteristics. When links are added to the same SRLG group they will be treated similarly(assuming that the tie-breaker is enabled).

! Enable per-prefix FRR
eigrp-af-topology> fast-reroute per-prefix {all | route-map {}}

! Disable load-sharing when using tie-breakers
eigrp-af-topology> fast-reroute load-sharing disable
! Each tie-breaker is enabled and given a priority individually
eigrp-af-topology> fast-reroute tie-break {type} {priority}
! Lower priority is better

! SRLG configuration
int> srlg gid {gid}

Leak-map with summary routes

EIGRP stub with leak map

Advertised through a stub router TLV in hello messages.

Stub routers will:

  1. Not propagate learned routes unless matched in a leak-map
  2. Only advertise local route specified on the eigrp stub command(summary*,connected*,static and redistributed or receive-only)
  3. Never be queried by neighbors, except when connected to a stub-only link(common link among stub routers without non-stubs)

If a stub router is queried it will respond with a poison reverse unless the advertisement is allowed.

Local stub state can be verified with show ip protocols, neighbor stub state can be verified with sh ip eigrp neigh det.

Stub site

EIGRP Stub sites allow exchanging routing information within a site while still acting as a stub to all outside neighbors. When a route is received on a stub-site wan-interface it will be tagged with the site-id. Stub-site routers will not advertise the tagged routes out of the stub-site wan-interfaces.

Stub sites are only available when using named mode configuration.

eigrp-af> eigrp stub-site {id} 
eigrp-af-int> stub-site wan-interface

Troubleshooting

To be populated…

Study resources

Books used, ranked by most value for time spent:

The CCIE Enterprise Infrastructure Foundation book by Narbik Kocharians hasn’t been released at the time of writing this, but i suspect it will also be a very good resource for the EI.

I have also used the IOS XE 16.2.x configuration guide extensively.

Various links I’ve found useful:


Got feedback or a question?
Feel free to contact me at hello@torbjorn.dev