Quick Notes: Configuring and Troubleshooting EIGRP

** From: Routing TCP/IP, Volume I, 2nd Edition **

Configuring EIGRP

EIGRP requires only two steps to begin the routing process:

Enable EIGRP with the command router eigrp process-id. The process ID may be any number between 1 and 65535 (0 is not allowed).
Specify each major network on which to run EIGRP with the network command.

router eigrp 15
network 172.20.0.0

Earhart#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.20.10.0/24 is directly connected, Ethernet0
C 172.20.15.4/30 is directly connected, Serial0.1
C 172.20.15.0/30 is directly connected, Serial0.2
D 192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:01, Serial0.1
D 192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:01, Serial0.2
Earhart#

Tracing the route from Earhart to network 192.168.16.0, the path traverses a serial interface and an Ethernet interface, each with default metric values. The minimum bandwidth of the route will be that of the serial interface, and the delay will be the sum of the two interface delays.

BW_EIGRP(min) = 256 × 6476 = 1657856
DLY_EIGRP(sum) = 256 × (2000 + 100) = 537600

Therefore,
Metric = 1657856 + 537600 = 2195456

Unequal-Cost Load Balancing

Given up to 16 parallel routes of equal cost, EIGRP will do equal-cost load balancing under the same CEF/fast/process switching constraints as RIP. Unlike RIP, EIGRP can also perform unequal-cost load balancing.
The goal is to have Earhart perform unequal-cost load balancing across these two links—spreading the traffic load inversely proportional to the metrics of the link.
The variance command is used to determine which routes are feasible for unequal-cost load sharing.
Variance defines a multiplier by which a metric may differ, or vary, from the metric of the lowest-cost route.
The default variance is one, meaning that the metrics of multiple routes must be equal, to load balance.
The metric of Earhart’s route through S0.3 is 10514432/2172416 = 4.8 times larger than the metric of the S0.1 route. So to conduct unequal-cost load balancing over both links, the variance at Earhart should be five.

router eigrp 15
network 172.20.0.0
variance 5

The following three conditions must be met for a route to be included in unequal-cost load sharing:

The maximum-paths limit must not be exceeded as a result of adding the route to a load-sharing “group.”
The next-hop router must be metrically closer to the destination. That is, its metric for the route must be smaller than the local router’s metric. A next-hop router, being closer to the destination, is often referred to as the downstream router.
The metric of the lowest-cost route, when multiplied by the variance, must be greater than the metric of the route to be added.

Earhart#show ip route
Gateway of last resort is not set
172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks
C 172.20.10.0/24 is directly connected, Ethernet0
C 172.20.15.4/30 is directly connected, Serial0.1
C 172.20.15.0/30 is directly connected, Serial0.2
C 172.20.15.8/30 is directly connected, Serial0.3
D 192.168.17.0/24 [90/2172416] via 172.20.15.6, 00:00:02, Serial0.1
[90/10514432] via 172.20.15.10, 00:00:02, Serial0.3
D 192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:02, Serial0.2
Earhart#

Load sharing is per destination if the packet is fast switched or CEF switched using the default CEF configuration, and per packet if process switching is used or if the CEF configuration was modified.
CEF and fast switching have been turned off with no ip cef and no ip route-cache, and the router is performing unequal-cost, per packet load balancing.
For every five packets sent over the 1544K link (to next hop 172.20.15.6), one packet is sent over the 256K link (to next hop 172.20.15.10). This corresponds to the approximately five-to-one variance of the metrics of these two paths.

IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,
len 100, forward
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,
len 100, forward
Earhart#

Setting Maximum Paths

The maximum number of routes over which EIGRP can load balance is set with the maximum-paths paths command and paths may be any number from 1 to 16 in IOS 12.3(2)T and later.

router eigrp 15
variance 7
network 172.20.0.0
maximum-paths 2

The variance command ensures that any of the three routes to 172.18.0.0 is feasible; the maximum-paths command limits the load-sharing group to only the two best routes.
The first route table shows that Earhart was load balancing over the two links with the lowest of the three metrics, S0.4 and S0.5.
After a failure of the S0.4 link, the second route table shows that the router is now load balancing over the S0.5 and S0.6 links.
In each instance, the router will load balance inversely proportional to the metrics of the two paths.

Earhart#show ip route
Gateway of last resort is not set

D 172.18.0.0/16 [90/5514496] via 172.20.15.18, 00:00:16, Serial0.5
[90/3014400] via 172.20.15.14, 00:00:16, Serial0.4
172.20.0.0/16 is variably subnetted, 7 subnets, 2 masks
C 172.20.15.20/30 is directly connected, Serial0.6
C 172.20.15.16/30 is directly connected, Serial0.5
C 172.20.10.0/24 is directly connected, Ethernet0
C 172.20.15.4/30 is directly connected, Serial0.1
C 172.20.15.0/30 is directly connected, Serial0.2
C 172.20.15.12/30 is directly connected, Serial0.4
C 172.20.15.8/30 is directly connected, Serial0.3
D 192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:18, Serial0.1
[90/10537472] via 172.20.15.10, 00:00:18, Serial0.3
D 192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:19, Serial0.2
Earhart#

EIGRP: Holdtime expired
EIGRP: Neighbor 172.20.15.14 went down on Serial0.4

Earhart#show ip route
Gateway of last resort is not set
D 172.18.0.0/16 [90/5514496] via 172.20.15.18, 00:00:09, Serial0.5
[90/20514560] via 172.20.15.22, 00:00:09, Serial0.6
172.20.0.0/16 is variably subnetted, 7 subnets, 2 masks
C 172.20.15.20/30 is directly connected, Serial0.6
C 172.20.15.16/30 is directly connected, Serial0.5
C 172.20.10.0/24 is directly connected, Ethernet0
C 172.20.15.4/30 is directly connected, Serial0.1
C 172.20.15.0/30 is directly connected, Serial0.2
C 172.20.15.12/30 is directly connected, Serial0.4
C 172.20.15.8/30 is directly connected, Serial0.3
D 192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:26, Serial0.1
[90/10537472] via 172.20.15.10, 00:00:26, Serial0.3
D 192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:26, Serial0.2
Earhart#

Stub Routing

When an entry in a router’s EIGRP topology table changes for the worse (either the metric increases, or the successor is no longer accessible), if there is no feasible successor for the address, the entry goes into Active state, and the router sends query packets to all its neighbors.
A router that has EIGRP Stub neighbors will not send queries to the stubs, thereby eliminating the chance that a stub-configured remote site will cause stuck in active conditions, and routing instabilities in other parts of the network.

Johnson#
router eigrp 15
eigrp stub

No configuration changes are required on Earhart, the hub router.
The command eigrp stub causes Johnson to send updates containing its connected and summary routes only.
Johnson can be configured to include any combination of connected routes, summary routes, static routes, or routes that have been redistributed into EIGRP, with the command: eigrp stub {connected | redistributed | static | summary | receive-only}
Johnson can also be configured to not send any route information in updates, with the receive-only option. With the receive-only option, the remote router will not include any addresses in an update. Addresses connected to the Johnson router would have to be advertised to the rest of the network in some other way to ensure that traffic can reach the site, perhaps with static routes configured on the hub.
To verify a neighbor is configured as a stub router, use the command show ip eigrp neighbor detail on the hub router.

Earhart#show ip eigrp neighbor detail
IP-EIGRP neighbors for process 15
H Address Interface Hold Uptime SRTT RTO Q Seq Type
(sec) (ms) Cnt Num
7 172.20.33.2 Et1 11 00:00:10 12 200 0 13
Version 12.1/1.2, Retrans: 0, Retries: 0
6 10.15.15.253 Et2 11 00:00:10 12 200 0 6
Version 12.3/1.2, Retrans: 1, Retries: 0
5 172.20.15.22 Se0.6 11 00:00:13 298 1788 0 73
Version 12.3/1.2, Retrans: 0, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
4 172.20.15.14 Se0.4 11 00:00:13 927 5000 0 81
Version 12.3/1.2, Retrans: 0, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
3 172.20.15.18 Se0.5 10 00:00:13 817 4902 0 80
Version 12.3/1.2, Retrans: 0, Retries: 0
Stub Peer Advertising ( CONNECTED SUMMARY ) Routes
0 172.20.15.2 Se0.2 11 00:15:48 274 1644 0 13
Version 12.3/1.2, Retrans: 0, Retries: 0
2 172.20.15.10 Se0.3 13 00:45:40 72 570 0 59
Version 12.3/1.2, Retrans: 0, Retries: 0
1 172.20.15.6 Se0.1 11 00:46:01 61 366 0 57
Version 12.3/1.2, Retrans: 0, Retries: 0
Earhart#

Configuring stub routing with EIGRP greatly increases the scalability of an EIGRP network, by minimizing queries, and thus the amount of time that network outages require addresses to be in an active state.
Stub routing eliminates queries sent to the stub router, but it does nothing to hide the topology of the rest of the network from the stub’s point of view. Earhart can hide the topology of the rest of the network from the stubs. They don’t need to know about every individual subnet because all packets for each of the subnets are always forwarded to the hub. Earhart can accomplish this by summarizing addresses.

Address Summarization

interface Ethernet2
ip address 10.15.15.254 255.255.255.252
ip summary-address eigrp 15 172.0.0.0 255.0.0.0
ip summary-address eigrp 15 192.168.16.0 255.255.240.0

The ip summary-address eigrp command will automatically suppress the advertisement of the more specific networks.

Yeager#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

D 172.18.0.0/16 [90/3040000] via 10.15.15.254, 00:13:07, Ethernet0
D 172.20.0.0/16 [90/307200] via 10.15.15.254, 00:13:07, Ethernet0
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.1.0/24 is directly connected, Ethernet1
C 10.15.15.252/30 is directly connected, Ethernet0
192.168.17.0/27 is subnetted, 1 subnets
D 192.168.17.0 [90/2198016] via 10.15.15.254, 00:03:57, Ethernet0
D 192.168.16.0/24 [90/2221056] via 10.15.15.254, 00:01:51, Ethernet0
192.168.18.0/24 is variably subnetted, 2 subnets, 2 masks
D 192.168.18.24/29 [90/2221056] via 10.15.15.254, 00:13:09, Ethernet0
D 192.168.18.128/25 [90/2198016] via 10.15.15.254, 00:13:09, Ethernet0

Yeager#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C 10.10.1.0/24 is directly connected, Ethernet1
C 10.15.15.252/30 is directly connected, Ethernet0
D 172.0.0.0/8 [90/307200] via 10.15.15.254, 00:00:57, Ethernet0
D 192.168.16.0/20 [90/2198016] via 10.15.15.254, 00:00:57, Ethernet0

Authentication

MD5 cryptographic checksums are the only authentication supported in EIGRP.
The steps for configuring EIGRP authentication are

Define a key chain with a name.
Define the key or keys on the key chain.
Enable authentication on an interface and specify the key chain to be used.
Optionally configure key management.

EIGRP authentication is enabled and linked to a key chain on an interface with the commands ip authentication key-chain eigrp and ip authentication mode eigrp md5.

key chain Edwards
key 1
key-string PanchoBarnes
!
interface Serial0/0.1
ip address 172.20.15.6 255.255.255.252
ip authentication key-chain eigrp 15 Edwards
ip authentication mode eigrp 15 md5
interface Serial0/0.2
ip address 172.20.15.10 255.255.255.252
ip authentication key-chain eigrp 15 Edwards
ip authentication mode eigrp 15 md5

The commands accept-lifetime and send-lifetime are used for key-chain management.

Troubleshooting EIGRP

Neighbor tables and adjacencies must be verified, the query/response procedure of DUAL must be followed, and the influences of VLSM on automatic summarization must be considered.
Among the possible causes, the simplest causes should be examined first. These follow:

An incorrect interface address or mask
An incorrect EIGRP process ID
A missing or incorrect network statement

Stuck-In-Active Neighbors

When a route goes active and queries are sent to neighbors, the route will remain active until a reply is received for every query.
The active timer and SIA-retransmit timer are designed to prevent the neighbor from staying permanently active.
Both the active timer and the SIA-retransmit timer are set when a query is sent.
If the timers expire before a reply to the query is received, the route is declared stuck-in-active, the neighbor is presumed dead, and it is flushed from the neighbor table.
The SIA route and any other routes via that neighbor are eliminated from the route table.
DUAL will be satisfied by considering the neighbor to have replied with an infinite metric.
In reality, this sequence of events should never happen. The loss of Hellos should identify a disabled neighbor long before the active timer expires.
But what happens in large EIGRP networks where a query might keep going and going? Remember that queries cause the diffusing calculation to grow larger, whereas replies cause it to grow smaller. Queries must eventually reach the edge of the network, and replies must eventually begin coming back, but if the diameter of the diffusing calculation grows large enough, an active timer might expire before all replies are received. The result, flushing a legitimate neighbor from the neighbor table, is obviously destabilizing.
When chasing the cause of SIAs, close attention should be paid to the topology table in routers. If routes can be “caught” in the active state, the neighbors from whom queries have not yet been received should be noted.
This topology table shows several active routes, all of which are waiting for a reply from neighbor 10.1.2.1.

Gagarin#show ip eigrp topology
IP-EIGRP Topology Table for process 1
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply
r - Reply Status
A 10.11.1.0/24, 0 successors, FD is 3072128000, Q
1 replies, active 00:00:15, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.10.1.0/24, 0 successors, FD is 3584128000, Q
1 replies, active 00:00:15, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.9.1.0/24, 0 successors, FD is 4096128000, Q
1 replies, active 00:00:15, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.2.1.0/24, 1 successors, FD is Inaccessible, Q
1 replies, active ve 00:00:15, query-origin: Local origin
Remaining res:
via 10.1.2.1, r, Ethernet0
P 10.1.2.0/24, 1 successors, FD is 281600
via Connected, Ethernet0
A 10.6.1.0/24, 0 successors, FD is 3385160704, Q
1 replies, active 00:00:41, query-origin: Local origin
Remaining replies:
via 10.1.2.1, r, Ethernet0
A 10.27.1.0/24, 0 successors, FD is 3897160704, Q
--More-

The neighbor 10.1.2.1 has its reply status flag (r) set. That is the neighbor from which replies have not yet been received. There might be no problem with the neighbor itself or with the link to the neighbor, but this information points to the direction within the network topology in which the investigation should proceed.
Common causes of SIAs in larger EIGRP networks are heavily congested, low-bandwidth data links and routers with low memory or overutilized CPUs.
The careless adjustment of the bandwidth parameter on interfaces might be another cause of SIAs. Recall that EIGRP is designed to use no more than 50 percent of the available bandwidth of a link.
If the bandwidth is set artificially low in an attempt to manipulate routing choices, the EIGRP process might be starved.
A new timer, the SIA-retransmit timer, and the two new EIGRP packet types, SIA-query and SIA-reply, help to minimize SIAs and to push the reset of the neighbor to link that is actually having the problem responding to queries.
The SIA-retransmit timer is set to one-half the value of the Active timer, typically 90 seconds.
The routers will send up to three SIA-queries (assuming no reply has been received from the original address query) as long as SIA-replies are received, before resetting a neighbor. So as long as a neighbor router responds to the SIA-queries, it won’t be declared stuck-in-active and reset, for six minutes, assuming a default Active time of 180 seconds. This gives ample time for a large network to respond to queries.
But, say there is a problem on the link that is allowing enough Hellos to get through to keep the neighbors active, but the SIA-reply is not received within the SIA-retransmit time. If no SIA-reply is received within 90 seconds of a SIA-query, and no response to the original address query has been received, the router will reset neighbor and reply to the original query that the address is unreachable.
The SIA-retransmit timer does two things. If neighbors are responding to SIA-queries, large networks are given more time to respond to address queries. If neighbors are not responding, the neighbor is reset. Only the router that is not receiving responses from its neighbor will reset the adjacency. Before the SIA-retransmit timer was introduced, any router that did not receive a response to an active query after the Active timer expired would reset the neighbor adjacency, even if the problem was somewhere downstream in the network.
A good network design is the best solution to instabilities such as SIA routes. By using a combination of intelligent address assignment, route filtering, default routes, stub routing, and summarization, boundaries may be constructed in a large EIGRP network to restrict the size and scope of diffusing computations.

Network Playroom

Search This Blog