Contents
- Introduction
- Configuration
- Router IDs
- How Information is Exchanged with EIGRP
- Loop Prevention
- Topology Table
- EIGRP Convergence and Failure Detection
- Verification
- EIGRP Optimization
Introduction
Enhanced Interior Gateway Routing Protocol (EIGRP) is a Cisco-proprietary enhanced distance vector routing protocol. EIGRP uses an algorithm known as diffusing update algorithm (DUAL) to identify the lowest metric network paths. EIGRP ensures fast convergence using pre-calculated loop-free backup paths. EIGRP uses protocol-dependent modules (PDMs) to support network protocols such as IPv4 and IPv6. EIGRP is written so that the PDM is responsible for the functions that handle the route selection criteria for each network layer protocol. Current versions of EIGRP only support IPv4 and IPv6.Cisco released an informational RFC on EIGRP, RFC 7868, opening up EIGRP for implementation by other vendors. This makes it possible for EIGRP to be implemented in a multi-vendor enterprise network.
Distance vector protocols learn information about remote networks only from neighbors and therefore have a limited view of the network compared to link-state routers which learn route information from all routers in an area.
EIGRP has features unique from other distance vector protocols:
- It utilizes neighbors for sharing information and continuously monitors neighbor state
- Rapid convergence of EIGRP networks is enabled by using pre-calculated loop-free backup paths
- EIGRP sends incremental and bounded updates; it does not send periodic updates.
Updates are only sent when there is a topology change i.e.:
- A new network is added
- An existing network is withdrawn due to link or device failure
- Change of path metric
- EIGRP uses a composite metric that, by default, consists of cumulative delay and lowest path bandwidth. EIGRP can be configured to include additional parameters such as link load and reliability.
- EIGRP is the only routing protocol to-date to support unequal cost load balancing
A router can run multiple EIGRP processes. Each process operates under the context of an autonomous system, which represents a common routing domain. Routers within the same domain use the same metric calculation formula and exchange routes only with members of the same autonomous system. If there is a need or requirement for routes to be shared between different autonomous systems, then redistribution will have to be configured.
EIGRP uses IP protocol number 88. EIGRP uses both multicast and unicast to exchange the topology information. Neighbor discovery takes place through multicast packets. Once neighborships are formed, unicasts are used to synchronize the topology.
EIGRP and Other Routing Information Sources
The routing table (RIB) receives routing information from various sources. If a routing device is being informed about a route from various sources such as EIGRP, OSPF, IS-IS, BGP etc it uses the concept of administrative distance to rank the routing information from each source. The administrative distance (AD) can be considered as the level of trustworthiness of routing information from a given source. The lower the AD, the more trustworthy the routing information and the more likely that that routing information will be installed in the RIB in preference over other sources with higher AD. An AD of 255 represents an untrustworthy route.
EIGRP has an administrative distance of 90 for internal EIGRP-originated routes and 170 for routes that are redistributed into EIGRP from other sources such as OSPF (external routes). EIGRP summary routes have an AD of 5. The following table shows the ADs of some common routing protocols.
| Routing Source | Administrative Distance |
| Connected | 0 |
| Static | 1 |
| EIGRP Summary | 5 |
| eBGP | 20 |
| EIGRP | 90 |
| OSPF | 110 |
| IS-IS | 115 |
| RIP | 120 |
| EIGRP-External | 170 |
| iBGP | 200 |
Configuration
EIGRP supports two configuration modes: named and classic. The original EIGRP configuration mode was classic-mode. The named-mode was introduced in IOS versions 15.2. It is backward compatible with classic EIGRP; a router configured using named-mode can form a neighborship with an EIGRP peer whose configuration is in classic-mode.
Classic Mode
In classic-mode, EIGRP configuration is split into two sections:
- EIGRP router configuration mode: general EIGRP configuration including commands that affect the EIGRP topology table.
- Interface mode: interface-specific commands that are configured individually at the interface include authentication, hello interval, split-horizon and summary-route advertisements. These usually affect information sharing and neighbor formation between connected neighbors.
EIGRP classic-mode supports 32-bit metrics.
For this configuration of EIGRP, we use the following interface IP address configuration:
R1(config)#do show ip interface brief | ex una
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0/0 10.0.12.1 YES manual up up
GigabitEthernet1/0 10.1.13.1 YES manual up up
FastEthernet3/0 10.0.16.1 YES manual up up
Loopback10 10.1.10.1 YES manual up up
Loopback11 10.1.11.1 YES manual up up
Loopback12 10.1.12.1 YES manual up up
To configure EIGRP using classic-mode:
-
Initialize the EIGRP routing process with the global configuration command
router eigrp <AS>where AS is the autonomous system number and is in the range 1 - 65535. The autonomous system number must match for neighboring devices to become EIGRP peers.R1(config)#router eigrp 1
-
Configure the EIGRP Router ID (RID): The router ID is used to uniquely identify the device and its
advertised routes in the EIGRP autonomous system.
R1(config-router)#eigrp router-id 1.1.1.1
- Identify the interfaces whose network addresses are to be advertised using the EIGRP router mode command
network <ip-address> <wildcard-mask>. The optional subnet mask can be omitted to advertise IP addresses of all interfaces that are subnets of the classful network for that network statement.R1(config-router)#network 10.0.12.0 0.0.0.3
R1(config-router)#network 10.0.16.1 0.0.0.0
R1(config-router)#network 10.1.10.0 0.0.0.255
R1(config-router)#network 10.1.11.0 0.0.0.255
R1(config-router)#network 10.1.12.0 0.0.0.255
The wildcard mask:
- Can be as specific as 0.0.0.0 where it identifies an interface by its exact IP address.
- It can be as general as 0.0.0.3 where it identifies the network that a specific interface belongs to.
- It can also be as general as 0.0.255.255 where the last two octets can be ignored when matching the network address. With this type of wildcard mask, EIGRP can be activated on many interfaces.
A subnet mask can be configured instead of the wildcard mask. However, the IOS will convert the subnet mask to wildcard mask in the saved configuration.
Confirm the EIGRP configuration by issuing the privileged-mode command: show ip protocols.
R1(config)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 1.1.1.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.0.12.0/30
10.0.16.1/32
10.1.10.0/24
10.1.11.0/24
10.1.12.0/24
Routing Information Sources:
Gateway Distance Last Update
10.0.12.2 90 00:11:40
Distance: internal 90 external 170
R1(config)#
EIGRP Classic Metric Calculation
The EIGRP metric calculation formula is based on the IGRP metric formula. However, calculated metric is then multiplied by 256 to change it from 24-bit to 32-bit. EIGRP uses multiple parameters to calculate the metric for a path hence the term composite metric. Metric calculation uses bandwidth and delay by default but can be configured to include interface load and reliability too. EIGRP selects paths with the lowest composite metric based on the following parameters:
Bandwidth: lowest bandwidth along path in kbps. The bandwidth value
can also be retrieved from the configured interface bandwidth using command
bandwidth <value>
Delay: cumulative delay along the path in tens of microseconds.
If the K-values are modified to include load and reliability in metric calculation:
Load: highest load along path.
Reliability: lowest reliability along path.
The bandwidth is scaled by inverse bandwidth and 107 × 256. Delay is scaled by 256. The composite metric is computed as follows:
metric = [K1 × bandwidth + (K2 × bandwidth) ÷ (256 - Load) + K3 × delay ]
If K5 != 0, metric = metric × [K5 ÷ (Reliability + K4)]
K-values allow for manual weighting. The default K-values are: K1=1 and K3=1, K2=0, K4=0 and K5=0. Based on the default
K-values, the default composite metric uses minimum path bandwidth and cumulative delay for metric calculation.
The default K-values can be modified with the EIGRP command:
metric weights tos K1 K2 K3 K4 K5
metric weights 0 1 0 1 0 0
TOS is always zero(0) and the values K1 to K5 are in the range 1 - 255. The K-values can be viewed using the command
show ip protocols.
The K-values must match between two neighboring devices for adjacency to occur.
It is recommended to use EIGRP named-mode on platforms that support it.
Named Mode (Multi Address-family Mode)
With EIGRP named-mode configuration, all the EIGRP configuration is done in one location; under the
router eigrp configuration mode. Named mode supports IPv4
and IPv6 including Virtual Routing and Forwarding [VRF]
instances. EIGRP named configuration is also known as multi-address family configuration mode.
Unlike classic-mode, named-mode supports newer features such as wide metrics, IPv6 VRF Lite.
EIGRP named configuration makes it possible to run multiple instances (different autonomous system numbers) under the same EIGRP process. EIGRP named-mode provides a hierarchical configuration in three subsections: address-family, interface and topology.
-
Address Family: This sub-mode contains settings that are relevant to the
autonomous system-wide operations such as:
- local networks to advertise
- K-values
- Logging settings
- Static neighbor configuration
- Stub router settings
-
Interface: This sub-mode contains settings that are specific to the
neighborship over a particular interface and interface specific settings such as:
- hello interval
- split-horizon
- passive-interface settings
- next-hop settings
- authentication
- BFD
- bandwidth percentage
- summary route
- Specific interface: commands configured for a specific interface
using the EIGRP address-family command
af-interface <interface-name>. Configurations made under a specific interface apply to that interface. - Default interface: for the default interface
using the command
af-interface default. Configurations made under the default interface apply to all interfaces on the router.
-
Topology: This sub-mode contains configurations that affect the EIGRP topology database and how routes are presented to the
router's RIB. Configurations that can be done under the topology base section include:
- route redistribution
- administrative distance
- unequal-cost load-balancing using
variancecommand - maximum-paths settings for load-balancing
- offset-lists for traffic engineering
- route filtering using distribute-lists
- SNMP parameter settings
- traffic share settings
The following interface configuration will be used in the discussion of EIGRP named-mode configuration.
R6(config-if)#do show ip interface brief
Interface IP-Address OK? Method Status Protocol
Ethernet0/0 unassigned YES NVRAM administratively down down
GigabitEthernet0/0 10.100.0.1 YES manual up up
GigabitEthernet1/0 10.0.26.2 YES manual up up
GigabitEthernet2/0 unassigned YES NVRAM administratively down down
FastEthernet3/0 10.0.16.2 YES manual up up
FastEthernet3/1 unassigned YES NVRAM administratively down down
FastEthernet4/0 unassigned YES NVRAM administratively down down
FastEthernet4/1 unassigned YES NVRAM administratively down down
POS5/0 unassigned YES NVRAM administratively down down
POS6/0 unassigned YES NVRAM administratively down down
Loopback10 10.6.10.1 YES manual up up
Loopback11 10.6.11.1 YES manual up up
Loopback12 10.6.12.1 YES manual up up
R6(config-if)#
Step 1: Enable the EIGRP process with the config mode command router eigrp <instance-name>
R6(config)#router eigrp EIGRP_NAMED
The configured EIGRP instance is EIGRP_NAMED.
Step 2: Configure the appropriate address family and autonomous system number:
R6(config-router)#address-family ipv4 autonomous-system 1
The configured autonomous system number is 1.
Step 3: Configure the EIGRP router ID (RID):
R6(config-router-af)#eigrp router-id 6.6.6.6
Step 4: Configure networks that are to be advertised using the network command:
network <ip-address> <wildcard-mask>
R6(config-router-af)#network 10.6.0.0 0.0.255.255
R6(config-router-af)#network 10.0.16.2 0.0.0.0
*Sep 14 17:13:40.351: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.16.1 (FastEthernet3/0) is up: new adjacency
R6(config-router-af)#network 10.0.26.0 0.0.0.3
*Sep 14 17:13:52.967: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.26.1 (GigabitEthernet1/0) is up: new adjacency
Verify configured EIGRP settings:
R6(config-router-af)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 6.6.6.6
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 9
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.0.16.2/32
10.0.26.0/30
10.6.0.0/16
Routing Information Sources:
Gateway Distance Last Update
10.0.26.1 90 00:00:33
10.0.16.1 90 00:00:33
Distance: internal 90 external 170
R6(config-router-af)#
With named-mode, the metric weights include a new K-value, K6, which by default, has a value of 0. K6 adds an extended attribute to measure jitter, energy, or other future parameter.
As long as K-values K1 through K5 are the same and K6 is not set i.e. zero, devices configured using EIGRP classic mode are able to form neighborships with devices configured using named-mode. EIGRP is able to detect when a neighbor is configured using classic-mode. EIGRP unscales its 64-bit metric to 32-bit metric. This conversion results in loss of clarity if routes pass through a mixture of classic metric and wide metric devices. It is best to configure devices using the same EIGRP configuration mode.
EIGRP Wide Metric Calculation
The EIGRP metric calculation formula has been scaled to account for links above 10Gbps.
In classic EIGRP, bandwidth was calculated using the formula:
bandwidth = 107 × 256 ÷ int_bw.
All links with a bandwidth of 10,000,000 or higher were given the same bandwidth value of 10Gbps. As bandwidth increases, visibility is lost i.e., 1GiE = 25560, 10GiE = 256, 20GiE = 256, 40GiE = 256. EIGRP couldn't distinguish between these types of links to select the lowest metric path to a destination.
When calculating the composite wide metric, the delay parameter has a minimum configurable delay of 10 microseconds. As bandwidth increases, delay visibility is lost as it does not change: 1GiE = 10 microseconds, 10GiE = 10 microseconds, 20GiE = 10 microseconds.
Wide metrics address the issue of scalability with higher-capacity interfaces.
EIGRP wide metrics scale by 65,535 to accommodate higher-speed links and also cater for smaller delay values.
This provides support for interface speeds up to 655 terabits per second (65,535 × 107) without any scalability issues.
Wide metric is 64-bit as shown in the output of the command show ip protocols.
R6(config-router-af)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 6.6.6.6
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
...
The bandwidth problem is fixed by scaling it higher:
Bandwidth = 107 × 65536 ÷ int_bw
The delay problem is fixed by moving to picoseconds:
Delay = delay(pico) × 65536 ÷ 107
EIGRP Wide Metric Formula
Bandwidth is referred to as throughput in wide metric calculation:
Throughout = K1 × (EIGRP bandwidth × EIGRP_WIDE_SCALE) ÷ Interface Bandwidth in kbps
EIGRP_WIDE_SCALE is a constant with the value 65535. Delay is now referred to as latency in wide metric calculation. Latency is the total interface delay measured in picoseconds;
Latency = K3 × (Delay × EIGRP_WIDE_SCALE) ÷ EIGRP_DELAY_PICO
Default metric is still the same formula:
Metric = (K1 × min (throughput)) + (K3 × sum (latency))
Wide metrics are backwards compatible with classic EIGRP.
Wide Metric and RIB Scaling
Routing Information Base (RIB) only supports 32-bit metrics. After EIGRP DUAL,
the 64-bit EIGRP wide metric is scaled down to fit in the 32-bit RIB metric size
using the RIB-scale value in the formula 32-bit metric = 64-bit metric × (1 ÷ rib-scale).
This default RIB-scale value can be modified using the command:
metric rib-scale <1 - 255> in EIGRP named-mode
address-family sub-mode.
RIB metric = Feasible Distance × (1 ÷ 128)
Modifying the rib-scale has a direct impact on the metrics of routes. When the
metric rib-scale command is issued, all
EIGRP routes in the RIB are cleared and replaced with recalculated metrics.
NOTE: Classic EIGRP does not include a provision for modifying the RIB scale as it is not required because classic-mode
EIGRP metric values are already 32-bit values. As a result, RIB-scale value is not displayed in the output of the command
show ip protocols on device configured using classic-mode. The command
metric rib-scale <value> is excluded in the classic EIGRP mode configuration.
The following configurations and output show the effect of modifying the rib-scale on the metric values.
The command show ip protocols shows the currently configured rib-scale value.
In this example, it has the default value of 128.
R7#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_R7) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 7.7.7.7
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 17
Total Redist Count: 0
.....
R7#
The routing table displays the 32-bit metric for the route 192.168.96.0/20.
R7#show ip route 192.168.96.0
Routing entry for 192.168.96.0/20, supernet
Known via "eigrp 1", distance 90, metric 114952, type internal
Redistributing via eigrp 1
Last update from 10.100.0.1 on GigabitEthernet0/0, 01:00:28 ago
Routing Descriptor Blocks:
* 10.100.0.1, from 10.100.0.1, 01:00:28 ago, via GigabitEthernet0/0
Route metric is 114952, traffic share count is 1
Total delay is 160 microseconds, minimum bandwidth is 155000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 5
The EIGRP topology table shows the metric of the paths for the network 192.168.96.0/20 before the metric rib-scale is modified.
R7#show ip eigrp topology 192.168.96.0
EIGRP-IPv4 VR(EIGRP_R7) Topology Entry for AS(1)/ID(7.7.7.7)
%Entry 192.168.96.0/24 not in topology table
R7#show ip eigrp topology 192.168.96.0/20
EIGRP-IPv4 VR(EIGRP_R7) Topology Entry for AS(1)/ID(7.7.7.7) for 192.168.96.0/20
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 14713889, RIB is 114952
Descriptor Blocks:
10.100.0.1 (GigabitEthernet0/0), from 10.100.0.1, Send flag is 0x0
Composite metric is (14713889/14058529), route is Internal
Vector metric:
Minimum bandwidth is 155000 Kbit
Total delay is 160000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 5
Originating router is 10.200.45.1
10.100.1.3 (FastEthernet4/0), from 10.100.1.3, Send flag is 0x0
Composite metric is (23592960/14713889), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 260000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 6
Originating router is 10.200.45.1
10.100.1.4 (FastEthernet4/0), from 10.100.1.4, Send flag is 0x0
Composite metric is (22282240/13403169), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 240000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4
Originating router is 10.200.45.1
10.100.1.1 (FastEthernet4/0), from 10.100.1.1, Send flag is 0x0
Composite metric is (22937600/14058529), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 250000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 5
Originating router is 10.200.45.1
RIB-Scale Modification
Sometimes, the 64-bit FD of a route is so large that scaling it by the default RIB-scale value of 128 the EIGRP topology will still display the feasible distance as "FD is Infinity". In such a case, the RIB-scale will need to be modified to a higher value such that the resulting FD value is able to fit into the RIB.
The metric rib-scale value is modified from 128 to 192.
R7#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#router eigrp EIGRP_R7
R7(config-router)#address-family ipv4 unicast autonomous-system 1
R7(config-router-af)#metric rib-scale 192
R7(config-router-af)#
R7(config-router-af)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_R7) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 192
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 7.7.7.7
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 17
...
After modifying the rib-scale, all the routes in the RIB learned via EIGRP are cleared from the routing table and recalculated in the topology table and re-installed into the RIB with new metric values. The effect of the modified metric rib-scale can be seen from the recalculation of the metric from 114952 to 76634. Modification of the RIB-scale value does not affect the 64-bit wide-metric values
R7(config-router-af)#do show ip route 192.168.96.0
Routing entry for 192.168.96.0/20, supernet
Known via "eigrp 1", distance 90, metric 76634, type internal
Redistributing via eigrp 1
Last update from 10.100.0.1 on GigabitEthernet0/0, 00:00:21 ago
Routing Descriptor Blocks:
* 10.100.0.1, from 10.100.0.1, 00:00:21 ago, via GigabitEthernet0/0
Route metric is 76634, traffic share count is 1
Total delay is 160 microseconds, minimum bandwidth is 155000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 5
R7(config-router-af)#
R7(config-router-af)#do show ip eigrp topology 192.168.96.0/20
EIGRP-IPv4 VR(EIGRP_R7) Topology Entry for AS(1)/ID(7.7.7.7) for 192.168.96.0/20
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 14713889, RIB is 76634
Descriptor Blocks:
10.100.0.1 (GigabitEthernet0/0), from 10.100.0.1, Send flag is 0x0
Composite metric is (14713889/14058529), route is Internal
Vector metric:
Minimum bandwidth is 155000 Kbit
Total delay is 160000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 5
Originating router is 10.200.45.1
10.100.1.3 (FastEthernet4/0), from 10.100.1.3, Send flag is 0x0
Composite metric is (23592960/14713889), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 260000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 6
Originating router is 10.200.45.1
10.100.1.4 (FastEthernet4/0), from 10.100.1.4, Send flag is 0x0
Composite metric is (22282240/13403169), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 240000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4
Originating router is 10.200.45.1
10.100.1.1 (FastEthernet4/0), from 10.100.1.1, Send flag is 0x0
Composite metric is (22937600/14058529), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 250000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 5
Originating router is 10.200.45.1
R7(config-router-af)#
Conversion of Classic Configuration to Named-mode Configuration
Converting EIGRP classic to named-mode is done by configuring the following command in EIGRP classic-mode:
eigrp upgrade-cli
The conversion results in a graceful restart of the EIGRP process without the loss of neighborship or route information. Conversion is automated as of IOS version 15.45.
EIGRP Router IDs
The router ID (RID) is a 32-bit number that uniquely identifies an EIGRP router in an autonomous system. It also serves as a loop-prevention mechanism. The RID is set automatically (default) or can be configured manually. When the EIGRP process initializes, the EIGRP router ID is set in the following order of criteria:
- The highest IPv4 address of any "up" loopback interface.
- The highest IPv4 address of any "up" physical interfaces.
Router IDs are used during the origination and redistribution of routes. EIGRP devices only accept routes with different originator router IDs. Remote routes with duplicate RIDs are discarded by the local router because EIGRP will assume that the route was locally originated. This discarding behaviour is performed on both internal and external routes.
To observe duplicate RID problems in real-time, issue the privileged mode command: show ip eigrp events
R1(config-router)#do show ip route eigrp
Codes: L - local, C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 18 subnets, 7 masks
D 10.0.26.0/30 [90/28416] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/3072] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.3.8.0/21 [90/130816] via 10.200.13.2, 00:01:44, GigabitEthernet1/0
D 10.7.10.0/24 [90/28416] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/3072] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.7.11.0/24 [90/28416] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/3072] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.7.12.0/24 [90/28416] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/3072] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.8.0.0/16 [90/28416] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/3328] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.8.0.0/19 [90/3072] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.100.0.0/29 [90/28416] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/3328] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.100.1.0/29 [90/3072] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.100.68.0/24 [90/30976] via 10.0.16.2, 00:01:44, FastEthernet3/0
[90/28672] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.200.23.0/30
[90/28416] via 10.200.13.2, 00:01:44, GigabitEthernet1/0
[90/28416] via 10.0.12.2, 00:01:44, GigabitEthernet0/0
D 10.200.34.0/30
[90/3072] via 10.200.13.2, 00:01:44, GigabitEthernet1/0
R1(config-router)#
R1(config-router)#do show ip eigrp topology
EIGRP-IPv4 Topology Table for AS(1)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.7.12.0/24, 2 successors, FD is 3072
via 10.0.12.2 (3072/2816), GigabitEthernet0/0
via 10.0.16.2 (28416/2816), FastEthernet3/0
P 10.3.8.0/21, 1 successors, FD is 130816
via 10.200.13.2 (130816/128256), GigabitEthernet1/0
P 10.200.23.0/30, 2 successors, FD is 28416
via 10.0.12.2 (28416/28160), GigabitEthernet0/0
via 10.200.13.2 (28416/28160), GigabitEthernet1/0
P 10.200.13.0/30, 1 successors, FD is 2816
via Connected, GigabitEthernet1/0
P 10.7.10.0/24, 2 successors, FD is 3072
via 10.0.12.2 (3072/2816), GigabitEthernet0/0
via 10.0.16.2 (28416/2816), FastEthernet3/0
P 10.200.34.0/30, 1 successors, FD is 3072
via 10.200.13.2 (3072/2816), GigabitEthernet1/0
P 10.8.0.0/19, 1 successors, FD is 3072
via 10.0.12.2 (3072/2816), GigabitEthernet0/0
P 10.8.0.0/16, 1 successors, FD is 3328
via 10.0.12.2 (3328/3072), GigabitEthernet0/0
via 10.0.16.2 (28416/2816), FastEthernet3/0
P 10.0.16.0/30, 1 successors, FD is 28160
via Connected, FastEthernet3/0
P 10.100.0.0/29, 1 successors, FD is 3328
via 10.0.12.2 (3328/3072), GigabitEthernet0/0
via 10.0.16.2 (28416/2816), FastEthernet3/0
P 10.100.68.0/24, 2 successors, FD is 28672
via 10.0.12.2 (28672/28416), GigabitEthernet0/0
via 10.0.16.2 (30976/28416), FastEthernet3/0
P 10.7.11.0/24, 2 successors, FD is 3072
via 10.0.12.2 (3072/2816), GigabitEthernet0/0
via 10.0.16.2 (28416/2816), FastEthernet3/0
P 10.100.1.0/29, 1 successors, FD is 3072
via 10.0.12.2 (3072/2816), GigabitEthernet0/0
P 10.0.26.0/30, 2 successors, FD is 3072
via 10.0.12.2 (3072/2816), GigabitEthernet0/0
via 10.0.16.2 (28416/2816), FastEthernet3/0
P 10.0.12.0/30, 1 successors, FD is 2816
via Connected, GigabitEthernet0/0
R1(config-router)#
R1(config-router)#eigrp router-id 2.2.2.2
R1(config)#do show ip eigrp events
....
461 06:52:55.763 Metric set: 10.7.10.0/24 metric(Infinity)
462 06:52:55.759 Ignored route, metric: 10.200.23.0/30 metric(30976)
463 06:52:55.759 Ignored route, dup routerid int: 2.2.2.2
464 06:52:55.759 Ignored route, metric: 10.0.12.0/30 metric(28672)
465 06:52:55.759 Ignored route, dup routerid int: 2.2.2.2
466 06:52:55.759 Metric set: 10.100.1.0/29 metric(30720)
467 06:52:55.759 Update reason, delay: new if delay(Infinity)
468 06:52:55.759 Update sent, RD: 10.100.1.0/29 metric(Infinity)
469 06:52:55.759 Update reason, delay: metric chg delay(Infinity)
470 06:52:55.759 Update sent, RD: 10.100.1.0/29 metric(Infinity)
471 06:52:55.759 Route installed: 10.100.1.0/29 10.0.16.2
472 06:52:55.759 Route installing: 10.100.1.0/29 10.0.16.2
473 06:52:55.759 Find FS: 10.100.1.0/29 metric(Infinity)
474 06:52:55.759 Rcv update met/succmet: metric(30720) metric(28160)
475 06:52:55.759 Rcv update dest/nh: 10.100.1.0/29 10.0.16.2
476 06:52:55.759 Metric set: 10.100.1.0/29 metric(Infinity)
477 06:52:55.755 Metric set: 10.100.0.0/29 metric(28416)
478 06:52:55.755 Update reason, delay: new if delay(Infinity)
479 06:52:55.755 Update sent, RD: 10.100.0.0/29 metric(Infinity)
480 06:52:55.755 Update reason, delay: metric chg delay(Infinity)
481 06:52:55.755 Update sent, RD: 10.100.0.0/29 metric(Infinity)
482 06:52:55.755 Route installed: 10.100.0.0/29 10.0.16.2
483 06:52:55.755 Route installing: 10.100.0.0/29 10.0.16.2
484 06:52:55.755 Find FS: 10.100.0.0/29 metric(Infinity)
485 06:52:55.755 Rcv update met/succmet: metric(28416) metric(2816)
486 06:52:55.755 Rcv update dest/nh: 10.100.0.0/29 10.0.16.2
487 06:52:55.755 Metric set: 10.100.0.0/29 metric(Infinity)
488 06:52:55.755 Metric set: 10.0.26.0/30 metric(28416)
489 06:52:55.755 Update reason, delay: new if delay(Infinity)
490 06:52:55.755 Update sent, RD: 10.0.26.0/30 metric(Infinity)
491 06:52:55.755 Update reason, delay: metric chg delay(Infinity)
492 06:52:55.755 Update sent, RD: 10.0.26.0/30 metric(Infinity)
493 06:52:55.751 Route installed: 10.0.26.0/30 10.0.16.2
494 06:52:55.751 Route installing: 10.0.26.0/30 10.0.16.2
495 06:52:55.751 Find FS: 10.0.26.0/30 metric(Infinity)
496 06:52:55.751 Rcv update met/succmet: metric(28416) metric(2816)
497 06:52:55.751 Rcv update dest/nh: 10.0.26.0/30 10.0.16.2
498 06:52:55.751 Metric set: 10.0.26.0/30 metric(Infinity)
499 06:52:55.679 Rcv peer INIT: 10.0.16.2 FastEthernet3/0
500 06:52:54.987 NDB delete: 10.200.34.0/30 1
*Oct 5 06:52:54.827: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is down: route configuration changed
*Oct 5 06:52:54.887: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.200.13.2 (GigabitEthernet1/0) is down: route configuration changed
*Oct 5 06:52:54.927: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.16.2 (FastEthernet3/0) is down: route configuration changed
*Oct 5 06:52:55.467: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.16.2 (FastEthernet3/0) is up: new adjacency
*Oct 5 06:52:56.003: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is up: new adjacency
*Oct 5 06:52:56.007: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.200.13.2 (GigabitEthernet1/0) is up: new138 06:47:22.611 FC sat rdbmet/succmet: metric(3072) metric(2816)
R1#
*Oct 5 07:03:38.979: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is down: Interface PEER-TERMINATION received
*Oct 5 07:03:39.503: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is up: new adjacency
*Oct 5 07:03:41.051: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is down: Interface PEER-TERMINATION received
*Oct 5 07:03:41.443: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is up: new adjacency
Information Exchange
Neighbor Formation
EIGRP requires a neighbor relationship to form between EIGRP devices before prefix exchange takes place. EIGRP uses neighborships to form a trusted bond between two similarly configured devices.
Router X must receive an initial Hello packet from Router Y before it can accept other EIGRP packet types. When a router X receives an EIGRP hello packet from another router Y, it attempts to become the neighbor of the router Y. When router X receives the first Hello packet from router Y, it places Y in a "pending state". X transmits a unicast "NULL" Update which has the initialization bit set and no routing data.With Y in the pending state, X will not send it any EIGRP messages and any other EIGRP messages received from Y will not be processed except ACK message type. If no ACK message is received, the timer on X will run out and the neighbor formation process will start again.
When the ACK message is received from, X changes its tracking state of Y from pending state to "Up" state. In the "up" state, X and Y exchange their topology table. This validates the bi-directional exchange of messages completing the "three-way handshake".
Before becoming neighbors, devices running EIGRP have to meet certain criteria. The following parameters must match for two devices to form a neighborship:
- Autonomous system numbers (ASNs): devices must be in the same EIGRP autonomous system.
- K-values: K1 and K3 are set to one (1), all others are set to zero by default.
- Authentication parameters: must match including Key ID and password (key string).
- Same subnet: the interfaces over which the neighbor relationship will be formed must reside in the same subnet.
Once the neighborship is formed, devices then share prefix information with each other. Each EIGRP process maintains a table of neighbors to ensure that they are alive and processing updates properly.
Normal neighborship establishment is automatic. EIGRP uses multicast hello packets with destination IPv4 address
224.0.0.10 and IPv6 address FF02::A.
Information exchange between EIGRP neighbors is done using multicast and unicast messages. Even in multicast environments, unicast is still used for route information
exchange. Acknowledgment packets are sent in reply to a received update. An acknowledgment packet is a Hello packet
without data such as K-values. Acknowledgement packets are usually sent in unicast to the sender of the update.
Neighbor Table
EIGRP neighbors are listed in the neighbor table. The EIGRP neighbor table
can be viewed using the privileged mode command show ip eigrp neighbors detail.
The detail keyword is optional.
R6#show ip eigrp neighbors
EIGRP-IPv4 VR(EIGRP_R6) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
6 10.100.1.2 Fa3/1 8 00:06:03 167 1002 0 4
5 10.100.0.2 Gi0/0 14 00:06:03 76 684 0 3
4 10.100.1.3 Fa3/1 6 00:07:50 124 744 0 9
3 10.100.0.3 Gi0/0 14 00:07:50 91 546 0 7
2 10.100.1.4 Fa3/1 6 00:16:15 846 5000 0 2
1 10.0.16.1 Fa3/0 10 00:16:15 104 624 0 9
0 10.0.26.1 Gi1/0 12 00:16:15 837 5000 0 0
R6#
| H: | Handle. An index number, starting from zero, assigned to a neighbor depending on when the neighborship was formed. The first neighbor has a Handle value of zero (0), the second one (1), and so on sequentially. |
| Address: | Source IP address of the neighbor that was used to establish an EIGRP adjacency with the local device. |
| Interface: | Interface of the local device through which the neighbor can be reached. |
| Hold (sec): | Hold timer value in seconds for the adjacency with the neighbor. This value is usually between 10 - 15. If this value decrements to zero, the neighbor is declared down and removed from the neighbor table. |
| Uptime | The duration that the neighborship has been in an up state (in hh:mm:ss). The neighbor with a handle of zero(0) usually has the highest uptime value. |
| SRTT (ms): | The computed smooth round-trip time (SRTT) for packets that are transmitted to and received from a neighbor. In effect, this reports how long it takes for this particular neighbor to respond to reliable packets. |
| RTO | The computed retransmission timeout for a neighbor. The value for this table object is computed as an aggregate average of the time required for packet delivery. It indicates how long the EIGRP will wait before retransmition if not ACK message is received. |
| Q Cnt | Number of EIGRP packets in the queue awaiting transmission to this neighbor. Values higher than zero indicate network congestion or non-responsive neighbor. Queue count should be zero (0) if converged with that of a neighbor. |
| Seq Num | The last sequence number of a packet transmitted to a neighbor. This value increases as the peers share updates. |
The command show ip eigrp neighbors detail displays more information of the neighbor adjacency.
R6#show ip eigrp neighbors detail
EIGRP-IPv4 VR(EIGRP_R6) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
6 10.100.1.2 Fa3/1 9 00:40:52 167 1002 0 14
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 14
Topology-ids from peer - 0
5 10.100.0.2 Gi0/0 10 00:40:52 76 684 0 13
Version 10.0/2.0, Retrans: 2, Retries: 0, Prefixes: 4
Topology-ids from peer - 0
4 10.100.1.3 Fa3/1 10 00:42:39 124 744 0 19
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 14
Topology-ids from peer - 0
3 10.100.0.3 Gi0/0 11 00:42:39 91 546 0 17
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 4
Topology-ids from peer - 0
2 10.100.1.4 Fa3/1 14 00:51:03 846 5000 0 32
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 8
Topology-ids from peer - 0
1 10.0.16.1 Fa3/0 14 00:51:03 104 624 0 29
Version 10.0/2.0, Retrans: 2, Retries: 0, Prefixes: 15
Topology-ids from peer - 0
0 10.0.26.1 Gi1/0 8 00:51:03 837 5000 0 30
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 14
Topology-ids from peer - 0
R6#
| Version: | EIGRP version information as reported by the neighbor. |
| Retrans: | Cumulative number of packets retransmitted to a neighbor while the neighbor is in an up state. |
| Retries: | Total number of times that an unacknowledged packet is sent to a neighbor. |
| Prefixes: | Total number of networks exchanged with this neighbor |
To display only the neighbors formed via a specific interface, add the interface parameter to the command
show ip eigrp neighbors <interface-id>.
R6#show ip eigrp neighbors Gigabitethernet0/0
EIGRP-IPv4 VR(EIGRP_R6) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
5 10.100.0.2 Gi0/0 9 00:56:08 76 684 0 13
3 10.100.0.3 Gi0/0 6 00:57:55 91 546 0 17
Static Configuration of Neighbors
In environments where multicast traffic is not possible, neighborship formation is still possible with static configuration that involves configuration of the neighbor's interface IP address. Static neighborships may also be a network design feature. Static neighborship configuration involves entering the following command:
neighbor <neighbor-ip-address> <interface-id>
The interface ID is the interface connecting to the neighbor.
The above command is entered in address-family mode for named EIGRP configuration and
eigrp router mode for classic configuration mode.
NOTE: Configuration of a static neighborship using a specific interface, say gigabitethernet0/0, will result in only the sending of unicast messages. The TTL of these unicast messages is set to one (1). Any previous neighborships formed automatically (using multicast messages) will be terminated because these neighborships depend on multicast messages which are now not being sent. The following log message will be displayed on the local router.
*Sep 28 16:22:33.187: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.2 (GigabitEthernet0/0) is down: Static peer configured
The following log message will be displayed on the remote router whose neighborship is being terminated due to configuration of the static EIGRP peering:
*Sep 28 16:22:29.079: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.12.1 (GigabitEthernet0/0) is down: Interface PEER-TERMINATION received
The EIGRP neighbor table can be filtered to display only statically configured
EIGRP neighbors using the commands show ip eigrp neighbors static
and show ip eigrp neighbors detail.
R1#show ip eigrp neighbors static
EIGRP-IPv4 VR(NAMED) Address-Family Neighbors for AS(1)
Static Address Interface
10.100.13.2 GigabitEthernet1/0
R1#
R1#show ip eigrp ne detail
EIGRP-IPv4 VR(NAMED) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
2 10.100.13.2 Gi1/0 14 00:02:49 228 1368 0 41
Static neighbor
Version 10.0/2.0, Retrans: 0, Retries: 0, Prefixes: 11
Topology-ids from peer - 0
0 10.0.12.2 Gi0/0 14 00:25:03 38 228 0 74
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 15
Topology-ids from peer - 0
1 10.0.16.2 Fa3/0 7 02:04:00 37 222 0 85
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 26
Topology-ids from peer - 0
R1#
EIGRP Neighbor Reset
To carry out a soft reset: clear ip eigrp neighbors soft
When executing a soft reset, the local device sends an update packet with the INIT and Restart flags set. Additionally, it sends all its successor and feasible successor routes in the same update. If all these successor and feasible successor routes are able to fit in one update packet, the EOT (End-of-Table) flag is also set.
The EIGRP peers respond to a reset by acknowledging the update and then resending their successor and feasible successor routes in an update packet with the Restart flag set.
Monitoring DUAL
To monitor DUAL activity: debug eigrp fsm.
The following log messages appear when the connecting interface of a remote device is shutdown.
R7#debug eigrp fsm
EIGRP Finite State Machine debugging is on
R7#
*Sep 28 16:19:14.355: EIGRP-IPv4(1): dest(10.200.45.0/30) not active
*Sep 28 16:19:14.359: EIGRP-IPv4(1): rcvupdate: 10.200.45.0/30 via 10.100.1.4 metric 26869760/20316160 on tid 0
*Sep 28 16:19:14.363: EIGRP-IPv4(1): Find FS for dest 10.200.45.0/30. FD is 72057594037927935, RD is 72057594037927935 on tid 0found
*Sep 28 16:19:14.371: DUAL: AS(1) RT installed 10.200.45.0/30 via 10.100.1.4
*Sep 28 16:19:14.371: DUAL: AS(1) Send update about 10.200.45.0/30. Reason: metric chg on tid 0
*Sep 28 16:19:14.375: DUAL: AS(1) Send update about 10.200.45.0/30. Reason: new if on tid 0
*Sep 28 16:19:14.403: EIGRP-IPv4(1): dest(10.200.45.0/30) not active
*Sep 28 16:19:14.407: EIGRP-IPv4(1): rcvupdate: 10.200.45.0/30 via 10.100.0.3 metric 27525120/26869760 on tid 0
*Sep 28 16:19:14.407: EIGRP-IPv4(1): Find FS for dest 10.200.45.0/30. FD is 26869760, RD is 26869760 on tid 0
*Sep 28 16:19:14.411: EIGRP-IPv4(1): 10.100.1.4 metric 26869760/20316160
*Sep 28 16:19:14.415: EIGRP-IPv4(1): 10.10
R7#0.0.3 metric 27525120/26869760 found Dmin is 26869760
*Sep 28 16:19:14.419: DUAL: AS(1) RT installed 10.200.45.0/30 via 10.100.1.4
*Sep 28 16:19:14.423: EIGRP-IPv4(1): dest(10.200.45.0/30) not active
*Sep 28 16:19:14.427: EIGRP-IPv4(1): rcvupdate: 10.200.45.0/30 via 10.100.0.1 metric 21626880/20971520 on tid 0
*Sep 28 16:19:14.427: EIGRP-IPv4(1): Find FS for dest 10.200.45.0/30. FD is 26869760, RD is 26869760 on tid 0
*Sep 28 16:19:14.431: EIGRP-IPv4(1): 10.100.1.4 metric 26869760/20316160
*Sep 28 16:19:14.435: EIGRP-IPv4(1): 10.100.0.1 metric 21626880/20971520
*Sep 28 16:19:14.435: EIGRP-IPv4(1): 10.100.0.3 metric 27525120/26869760 found Dmin is 21626880
*Sep 28 16:19:14.443: DUAL: AS(1) RT installed 10.200.45.0/30 via 10.100.1.4
*Sep 28 16:19:14.443: DUAL: AS(1) RT installed 10.200.45.0/30 via 10.100.0.1
*Sep 28 16:19:14.447: DUAL: AS(1) Send update about 10.200.45.0/30. Reason: metric chg on tid 0
*Sep 28 16:19:14.447: DUAL: AS(1) Send update about 10.200.45.0/30. Rea
R7#son: new if on tid 0
Inter-router Communication
EIGRP Packets
EIGRP uses five different packet types to communicate i.e. Hello, Update, Request, Reply, Query.
EIGRP sends packets using IP protocol 88. EIGRP uses multicast packets where possible to reduce bandwidth consumed on a link
(one packet to reach multiple devices); it uses unicast packets when necessary.
Communication between routers is done with multicast using the IPv4 multicast address
224.0.0.10 and the MAC address 01:00:5e:00:00:0a.
EIGRP uses Reliable Transport Protocol (RTP) to ensure that packets are delivered in order and to ensure that routers receive specific packets. The reliable transport protocol is responsible for guaranteed, ordered delivery of EIGRP packets to all neighbors. It supports intermixed transmission of multicast and unicast packets. Some EIGRP packets must be sent reliably.
For efficiency, reliability is provided only when necessary. For example, on a multiaccess network that has multicast capabilities, it is not necessary to send hello packets reliably to all neighbors individually. Therefore, EIGRP sends a single multicast hello with an indication in the packet informing the receivers that the packet need not be acknowledged using sequence number of zero (0). A sequence number is included in each EIGRP packet. The packet that has a sequence number of zero does not require a response from the recipient EIGRP router; all other values require an ACK packet that includes the original sequence number of the packet that they are acknowledging. Other types of packets (such as updates) require acknowledgment, which is indicated in the packet. The reliable transport has a provision to send multicast packets quickly when unacknowledged packets are pending. This provision helps to ensure that convergence time remains low in the presence of varying speed links.
EIGRP Packet Header
The EIGRP packet header can be found in each of the five EIGRP packet types. It contains the following fields:Header version: usually 2.
OpCode: The type of message in the packet. Eleven(11) types are supported; seven(7) are actively used: The OpCode for EIGRP's five packet types are: Update(1), Requests(2), Query(3), Reply(4), Hello(5), SIA Query(10), SIA Reply (11).
Checksum: ensures contents of packet have not been altered. If destination calculated checksum value is different from this value, the packet gets discarded.
Flags: used to define how the contents of the packet are handled by the destination. Four flags are defined: INIT, Conditionally Received (CR), Restart (RS), End-of-Table (EOT).
INIT
Used in initial establishment of communications with a new neighbor. It ensures that unicast bidirectional communication operates correctly. It also is used to instruct the new neighbor to advertise their full set of known routes. If acknowledgement is received, the neighbor will begin to send over its list of routes. These routes are not the complete content of its topology table but only the current successors that it is actively using.
Conditionally Received (CR)
Used when there is a problem with a neighbor properly acknowledging a packet in a specific retransmission time-out interval. Commonly used when slow or congested links exist or acknowledgement packets are not received back by the transmitting device in the proper amount of time. This results in EIGRP going into a recovery state where it uses unicast to ensure that packets are properly received.
Restart Flag (RS)
Often used in two different conditions: soft reset of a device and graceful restart occuring. A similar behaviour is expected in both conditions; the adjacency is maintained in both scenarios but the full information from neighbors is requested again. Typically, the INIT flag is set when the Restart flag is set and possibly EOT flag along with the full routing information. It reduces the packets required compared to starting from the beginning.
End-of-Table (EOT) Flag
Indicates all routes have been sent. That the route information in the current packet is the final one. If used along with a restart flag, old routes are removed by the receiving device that existed before the restart but doesn't exist after.
Sequence Number: To ensure the reliable transmission of certain packet types with EIGRP, a sequence number is set on certain packet types. Packets with a sequence number greater than zero require acknowledgement. The sequence number of the packet is contained in the acknowledgement message to acknowledge that packets have been received correctly. When a packet requires acknowledgement, the sequence number is set to a non-zero value. If the value is zero, then the packet does not require acknowledgement. The acknowledgement number is used along with a non-zero sequence number in a unicast packet exchange. When required, it is set to the same value as the acknowledged packet's sequence number wthin an acknoweledgement Hello packet and sent back to the initial sender.
Virtual Router ID: Used to identify the virtual router a packet is associated with. This is typically set to zero. This is not the Router ID configured when defining the EIGRP process.
Autonomous System Number: 16-bit number used to indicate the boundaries of a specific EIGRP network. All devices in the same EIGRP domain must have the same ASN to form neighborships.
The packet payload is variable and can be formatted in a number of different ways. They use a common type, length, value (TLV) format. Multiple combinations are possible.
Packet Types
OpCode is used to indicate the message type inside a packet. Message type is another term for packet type.
1. Hello Packet
Hello packets are used primarily for neighbor discovery and maintenance of the neighbor relationship where they act as keepalive messages. The hello-interval sets the time for hello packets to be transmitted by an interface. By default, the hello interval is 5 seconds. The Hello packet body contains sender's K-values, hold time and TLV (Type, Length Value) of the EIGRP version and TLV version used. Hello packets are often sent to multicast 224.0.0.10 on IPv4 networks and FF02::A on IPv6 networks. When multicast is not supported, Hello packets are sent to unicast addresses if the EIGRP neighbors where configured using static neighbor configuration.
The following output shows a packet capture of a Hello packet using Wireshark packet sniffing tool.
⊳ Frame 430: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on interface -, id 0
⊳ Ethernet II, Src: ca:01:03:cb:00:54 (ca:01:03:cb:00:54), Dst: IPv4mcast_0a (01:00:5e:00:00:0a)
⊳ Internet Protocol Version 4, Src: 10.0.16.1, Dst: 224.0.0.10
⋄ Cisco EIGRP
Version: 2
Opcode: Hello (5)
Checksum: 0xefd1 [correct]
[Checksum Status: Good]
⋄ Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
Sequence: 0
Acknowledge: 0
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
⋄ Parameters
Type: Parameters (0x0001)
Length: 12
K1: 1
K2: 0
K3: 1
K4: 0
K5: 0
K6: 0
Hold Time: 15
⋄ Software Version: EIGRP=10.0, TLV=2.0
Type: Software Version (0x0004)
Length: 8
EIGRP Release: 10.00
EIGRP TLV version: 2.00
Hello packets don't require acknowledgement hence considered unreliable; they have a sequence number of zero (0). They are used for acknowledgment of reliable packet types such as Update packets. When used in this capacity, the packet body is empty but with an acknowledgement number set to sequence number of the received packets and with the unicast destination address of the sender. Additionally, acknowledgment packets are sent in unicast so they do not use the destination multicast IP address of 224.0.0.10 and MAC address 01:00:5e:00:00:0a.
The following output is a packet capture of an Acknowledgement packet.
⊳ Frame 342: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface -, id 0
⊳ Ethernet II, Src: ca:06:05:94:00:54 (ca:06:05:94:00:54), Dst: ca:01:03:cb:00:54 (ca:01:03:cb:00:54)
⊳ Internet Protocol Version 4, Src: 10.0.16.2, Dst: 10.0.16.1
⋄ Cisco EIGRP
Version: 2
Opcode: Hello (5)
Checksum: 0xfdf5 [correct]
[Checksum Status: Good]
⋄ Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
Sequence: 0
Acknowledge: 4
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
Common EIGRP TLVs
TLV formats are different between versions 2.0 and 1.2. Version 2.0 devices are backwards compatible and can be used in mixed environments.
TLVs typically used are: parameter (0x0001), software version (0x0004), and authentication.
- Parameter TLV: includes local device's K-values and hold timer value.
These are used to determine compatibility
for neighbor establishment.
- Peer Termination: A peer termination is transmitted using a Hello packet with
all K-values set to 255. In EIGRP named-mode, K6 is set to 255 as well.
Cisco EIGRP
Version: 2
Opcode: Hello (5)
Checksum: 0xf1d1 [correct]
[Checksum Status: Good]
Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
Sequence: 0
Acknowledge: 0
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
Parameters: Peer Termination
Type: Parameters (0x0001)
Length: 12
K1: 255
K2: 255
K3: 255
K4: 255
K5: 255
K6: 255
Hold Time: 15
[Expert Info (Note/Response): Peer Termination]
[Peer Termination]
[Severity level: Note]
[Group: Response]
Software Version: EIGRP=10.0, TLV=2.0
Type: Software Version (0x0004)
Length: 8
EIGRP Release: 10.00
EIGRP TLV version: 2.00
- Peer Termination: A peer termination is transmitted using a Hello packet with
all K-values set to 255. In EIGRP named-mode, K6 is set to 255 as well.
- Software Version TLV: used to ensure devices are using a supported EIGRP version and TLV format.
- Authentication TLV: A third TLV is commonly seen in hello packets when using authentication. Authentication TLV in EIGRP supports MD5 and SHA256. It is used to relay authentication information including authentication type, Key ID, hash among others. When authentication is configured, the authentication TLV is added to all packet types except acknowledgement.
IPv4 and IPv6 TLVs: these are included in Update, Query, Reply, SIA-query and SIA-reply packets.
IPv4 TLVs
Multiple TLVs can be used to advertise the same types of networks depending on the specific EIGRP implementation. Originally, IPv4 prefixes were advertised in two types of TLV depending on whether the route originated inside the EIGRP or whether it originated outside EIGRP (0x0102 - Internal and 0x0103 - External) respectively.
IPv6 TLVs
IPv6 prefixes that were originally advertised using EIGRP (internal) were given the TLV value of 0x0402 and redistributed prefixes (external) 0x0403. Cisco used these TLV values in older software versions prior to TLV v1.5. Older TLVs have been deprecated in favor of multi-protocol TLVs not specific to the protocol type. When using these protocol-independent TLVs, 0x0602 is used for IPv4 and IPv6 internal routes and 0x0603 for external.
2. Update Packet
EIGRP Update packets are used to exchange new or updated information on different routes. The EIGRP update packet includes path attributes associated with each prefix. The EIGRP path attributes can include hop count, cumulative delay, minimum bandwidth. The attributes are updated by each hop along the way, allowing each router to independently identify the shortest path.
Updates utilize multicast or unicast depending on how the EIGRP neighbor relationship was formed. If establishing a new neighborship with another peer, then unicast will be used to update the new peer. If the information is currently known by the neighbor, when a topology change occurs, then multicast will tend to be used to ensure all EIGRP devices that exist on a common subnet can receive the information at the sametime. Regardless of the method used, update packets require acknowledgement and are considered reliable hence have a non-zero sequence number.Update packets can also serve the purpose of acknowledging a previously received Update packet. In such a scenario, acknowledge field of the EIGRP header of the Update packet will contain the sequence of the Update packet being acknowledged.
The following output shows a Wireshark packet capture of an EIGRP Update packet.
⊳ Frame 341: 232 bytes on wire (1856 bits), 232 bytes captured (1856 bits) on interface -, id 0
⊳ Ethernet II, Src: ca:01:03:cb:00:54 (ca:01:03:cb:00:54), Dst: ca:06:05:94:00:54 (ca:06:05:94:00:54)
⊳ Internet Protocol Version 4, Src: 10.0.16.1, Dst: 10.0.16.2
⋄ Cisco EIGRP
Version: 2
Opcode: Update (1)
Checksum: 0xb8d3 [correct]
[Checksum Status: Good]
⋄ Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive:
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not se
Sequence: 4
Acknowledge: 33
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
⋄ Internal Route = 10.0.12.0/30
Type: Internal Route (0x0602)
Length: 45
Topology: 0
AFI: IPv4 (1)
RouterID: 10.1.11.1
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 0
Delay: 10000000
Bandwidth: 1000000
Reserved: 0x0000
Flags
NextHop: 0.0.0.0
Prefix Length: 30
Destination: 10.0.12.0
⋄ Internal Route = 10.1.10.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 10.1.11.1
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1514
Hop Count: 0
Delay: 5000000000
Bandwidth: 8000000
Reserved: 0x0000
Flags
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.1.10.0
⋄ Internal Route = 10.1.11.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 10.1.11.1
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1514
Hop Count: 0
Delay: 5000000000
Bandwidth: 8000000
Reserved: 0x0000
Flags
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.1.11.0
⋄ Internal Route = 10.200.13.0/30
Type: Internal Route (0x0602)
Length: 45
Topology: 0
AFI: IPv4 (1)
RouterID: 10.1.11.1
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 0
Delay: 10000000
Bandwidth: 1000000
Reserved: 0x0000
Flags
NextHop: 0.0.0.0
Prefix Length: 30
Destination: 10.200.13.0
3. Query Packet
EIGRP Query packets are used when a route goes active because a successor is lost and no feasible successor exists. These packets are sent to all other neighbors that are not successor to the lost route. This query performs two functions:
- To request for an alternate path to the requested destination.
- To poison the routes whose next hop is the path that is now down.
The use of multiple query packets is possible for a single event such as the failure of a neighbor. In such a scenario, multiple routes may have been affected and gone active at the same time. Under such circumstances multiple query packets may be sent to the same destination neighbors but with different lists of active routes if all the active routes can not be fitted in a single packet. Query packets require acknowledgement from each neighbor making it a reliable mechanism.
Query packets can be sent in multicast or unicast depending on link limitations between neighbors or neighbor configuration.
The following output shows a Wireshark capture of an EIGRP Query packet:
⊳ Frame 393: 362 bytes on wire (2896 bits), 362 bytes captured (2896 bits) on interface -, id 0
⊳ Ethernet II, Src: ca:06:05:94:00:1c (ca:06:05:94:00:1c), Dst: IPv4mcast_0a (01:00:5e:00:00:0a)
⊳ Internet Protocol Version 4, Src: 10.0.26.2, Dst: 224.0.0.10
⋄ Cisco EIGRP
Version: 2
Opcode: Query (3)
Checksum: 0x7cd9 [correct]
[Checksum Status: Good]
⋄ Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
⋄ Sequence: 123
Acknowledge: 0
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
⋄ Internal Route = 10.8.14.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.14.0
⋄ Internal Route = 10.8.11.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.11.0
⋄ Internal Route = 10.8.13.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.13.0
⋄ Internal Route = 10.8.12.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.12.0
⋄ Internal Route = 10.8.15.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.15.0
⋄ Internal Route = 10.8.16.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.16.0
⋄ Internal Route = 10.8.10.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 255
Delay: Infinity
Bandwidth: 4294967295
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.10.0
From the packet capture of the EIGRP Query packet, the delay parameter is set to infinity and bandwidth to the maximum bandwidth value of 4294967295 (232) i.e. unreachable, and hop count is set to maximum at 255. These indicate that the local device has poisoned all paths to the prefixes in the Query packet that use the local router as a next hop.
4. Reply Packet
The EIGRP Reply packet is always sent as a response to a query regardless of whether a neighbor has a route to the destination or not. The reply packet acts as an acknowledgement for a query packet and contains the query packet's sequence number in its acknowledge field. If a neighbor does not have a route to the query destination, the reply is sent with an infinite delay metric.
TLVs are common to update, query and reply packets with corresponding information based on network reachability. The query process is iterative i.e. across the EIGRP domain. A reply packet is not sent back to the devices sending the query packets until an answering reply packet is received, This can be problematic on large networks.
Query scope can be limited:
- using route summarization
- stub routing
- route filtering
Two additional message types have been added: SIA-query and SIA-reply. SIA-query is sent at half query time if a reply is not seen. Its primary purpose is to verify the status of the query. SIA-reply is sent if that neighbor is still waiting for a reply to its query from its neighbor with an 'active' bit set. If that neighbor is completed with its processing of the query, it will send back either a reply or SIA-reply packet.
Everytime an SIA-reply packet is sent for a route, the query timer is reset to half the initial value. The exchange of SIA-query and SIA-reply packets can occur three different times. If the route is still being processed once a third SIA-reply packet is received, the route will be considered SIA. This will cause the neighborship to be reset on Cisco devices. RFC does require this.
The following output shows a Wireshark packet capture of an EIGRP Reply packet.
⊳ Frame 395: 362 bytes on wire (2896 bits), 362 bytes captured (2896 bits) on interface -, id 0
⊳ Ethernet II, Src: ca:02:03:ec:00:1c (ca:02:03:ec:00:1c), Dst: ca:06:05:94:00:1c (ca:06:05:94:00:1c)
⊳ Internet Protocol Version 4, Src: 10.0.26.1, Dst: 10.0.26.2
⋄ Cisco EIGRP
Version: 2
Opcode: Reply (4)
Checksum: 0x0d64 [correct]
[Checksum Status: Good]
⋄ Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
Sequence: 118
Acknowledge: 123
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
⋄ Internal Route = 10.8.14.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.14.0
⋄ Internal Route = 10.8.11.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.11.0
⋄ Internal Route = 10.8.13.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.13.0
⋄ Internal Route = 10.8.12.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.12.0
⋄ Internal Route = 10.8.15.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.15.0
⋄ Internal Route = 10.8.16.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.16.0
⋄ Internal Route = 10.8.10.0/24
Type: Internal Route (0x0602)
Length: 44
Topology: 0
AFI: IPv4 (1)
RouterID: 8.8.8.8
⋄ Wide Metric
Offset: 0
Priority: 0
Reliability: 255
Load: 1
MTU: 1500
Hop Count: 1
Delay: 11250000
Bandwidth: 1000000
Reserved: 0x0000
⋄ Flags
.... ...0 = Source Withdraw: False
.... ..0. = Candidate Default: False
.... .0.. = Route is Active: False
.... 0... = Route is Replicated: False
NextHop: 0.0.0.0
Prefix Length: 24
Destination: 10.8.10.0
5. Request Packet
The request packet is rarely used. It is used to obtain additional information from neighbors. They are used in route server applications but they appear to be deprecated.
Note: It is important to note that Update, Query, Reply, SIA-reply, SIA-query packets are sent reliably i.e. require acknowledgement packets.
EIGRP Loop Prevention
As a distance-vector routing protocol, EIGRP uses the following techniques as counter-measures for formation of loops in a network.:
- Split horizon
- Poison reverse
- Maximum hop count
Split Horizon
Split horizon is a loop prevention technique often implemented in distance vector routing protocols. It is enabled, by default, on all interfaces where EIGRP has been enabled. Split horizon follows this principle; "Never advertise a route out of the interface through which it was learned."
In some circumstances, it may be advisable to disable split horizon such as on
the hub's connecting interface in a hub and spoke DMVPN topology. To disable
split horizon, in interface mode, enter the command:
no split-horizon eigrp <autonomous-system>. In this
command, if the EIGRP keyword and autonomous-system number are excluded, then
split-horizon is disabled for RIP.
Poison Reverse
Poison reverse is often implemented along with split horizon on an EIGRP interface. It "poisons" routes back out interfaces it was learned on. EIGRP uses the infinite delay metric to "poison" the route and is only applied on successor routes/interfaces to reach a destination. It is also used in situations when a device wants to explicitly advertise route unreachability (that it no longer has a suitable path to a specific destination).
Maximum Hop Count
The default maximum hop count for EIGRP is 100 but a maximum of 255 is supported.
This can be increased using the command EIGRP router mode command:
metric maximum-hops <1 - 255>
Topology Table
EIGRP's topology table is a vital data structure in the operation of EIGRP together with the EIGRP neighbor table. It contains all routes as advertised by neighbors to an EIGRP router. DUAL then uses the topology table to identify loop-free backup routes. The topology table contains all the network prefixes advertised within an EIGRP autonomous system. Each entry in the table contains the following information:
- Network prefix
- EIGRP neighbors that advertised that prefix
- Metrics for each path as reported by the neighbor (advertised distance) and calculated by the local device (feasible distance) (reported distance and hop count)
- Values used for calculating the metric (load, reliability, total delay, and minimum bandwidth)
- Originating router i.e. the router that injected the route into the EIGRP domain.
- State of the route i.e. whether active or passive.
- The successors and feasible successors of the route.
- Feasible distance and reported distance of the route.
show ip eigrp topology is used to display the EIGRP topology table.
The feasible distance (FD) represents the total path metric from a local router to a destination. The advertised distance or reported distance (RD) is the path metric from a neighbor to the destination as advertised by the neighbor to the local device. The following configuration output shows the EIGRP topology table:
R8#show ip eigrp topology ?
A.B.C.D Network to display information about
A.B.C.D/nn Prefix /, e.g., 192.168.0.0/16
active Show only active entries
all-links Show all links in topology table
detail-links Show all links in topology table
pending Show only entries pending transmission
summary Show a summary of the topology table
zero-successors Show only zero successor entries
| Output modifiers
R8#show ip eigrp topology
EIGRP-IPv4 VR(EIGRP_8) Topology Table for AS(1)/ID(8.8.8.8)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.7.12.0/24, 1 successors, FD is 1392640
via 10.100.0.2 (1392640/163840), GigabitEthernet0/0
via 10.100.1.2 (13189120/163840), FastEthernet4/1
P 10.8.11.0/24, 1 successors, FD is 163840
via Connected, Loopback11
P 10.3.10.0/24, 1 successors, FD is 330956800
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 192.168.101.0/24, 1 successors, FD is 14713889
via 10.100.0.1 (14713889/14058529), GigabitEthernet0/0
via 10.100.1.1 (22937600/14058529), FastEthernet4/1
via 10.100.1.4 (22282240/13403169), FastEthernet4/1
P 10.3.12.128/25, 1 successors, FD is 330956800
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 10.200.23.0/30, 1 successors, FD is 14417920
via 10.100.0.1 (14417920/13762560), GigabitEthernet0/0
via 10.100.1.1 (20316160/13762560), FastEthernet4/1
via 10.100.1.4 (19660800/13107200), FastEthernet4/1
P 10.200.13.0/30, 1 successors, FD is 3276800
via 10.100.0.1 (3276800/2621440), GigabitEthernet0/0
via 10.100.1.4 (14417920/1966080), FastEthernet4/1
via 10.100.1.1 (15073280/2621440), FastEthernet4/1
P 10.7.10.0/24, 1 successors, FD is 1392640
via 10.100.0.2 (1392640/163840), GigabitEthernet0/0
via 10.100.1.2 (13189120/163840), FastEthernet4/1
P 192.168.100.0/24, 1 successors, FD is 14713889
via 10.100.0.1 (14713889/14058529), GigabitEthernet0/0
via 10.100.1.1 (22937600/14058529), FastEthernet4/1
via 10.100.1.4 (22282240/13403169), FastEthernet4/1
P 10.200.34.0/30, 1 successors, FD is 3932160
via 10.100.0.1 (3932160/3276800), GigabitEthernet0/0
via 10.100.1.4 (15073280/2621440), FastEthernet4/1
via 10.100.1.1 (15728640/3276800), FastEthernet4/1
P 10.8.12.0/24, 1 successors, FD is 163840
via Connected, Loopback12
P 10.0.16.0/30, 1 successors, FD is 13762560
via 10.100.0.1 (13762560/13107200), GigabitEthernet0/0
via 10.100.1.1 (19660800/13107200), FastEthernet4/1
P 10.3.12.0/25, 1 successors, FD is 330956800
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 10.100.0.0/29, 1 successors, FD is 1310720
via Connected, GigabitEthernet0/0
P 10.3.11.0/24, 1 successors, FD is 330956800
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 10.100.68.0/24, 1 successors, FD is 13107200
via Connected, FastEthernet4/0
P 10.7.11.0/24, 1 successors, FD is 1392640
via 10.100.0.2 (1392640/163840), GigabitEthernet0/0
via 10.100.1.2 (13189120/163840), FastEthernet4/1
P 10.8.10.0/24, 1 successors, FD is 163840
via Connected, Loopback10
P 10.200.45.0/30, 1 successors, FD is 14058529
via 10.100.0.1 (14058529/13403169), GigabitEthernet0/0
via 10.100.1.4 (21626880/12747809), FastEthernet4/1
via 10.100.1.1 (22282240/13403169), FastEthernet4/1
P 10.100.1.0/29, 1 successors, FD is 13107200
via Connected, FastEthernet4/1
P 10.0.26.0/30, 1 successors, FD is 1966080
via 10.100.0.1 (1966080/1310720), GigabitEthernet0/0
via 10.100.1.1 (13762560/1310720), FastEthernet4/1
via 10.100.1.4 (13762560/1310720), FastEthernet4/1
P 10.0.12.0/30, 1 successors, FD is 2621440
via 10.100.0.1 (2621440/1966080), GigabitEthernet0/0
via 10.100.1.1 (14417920/1966080), FastEthernet4/1
via 10.100.1.4 (13762560/1310720), FastEthernet4/1
R8#
Route States
Every path in the topology table is assigned one of two states; Active and Passive:
- Passive: for a route in passive state, at least one successor exists to the destination meaning a loop-free path has been learned by the local device and is placed in the topology table and routing table. The passive state is an indication of a stable network.
- Active: when a route is in active state, its successor path(s) has/have been lost and no feasible successors are available. This indicates that an active search for an alternative route has been initiated and queries have been sent to all available neighbors. EIGRP messages sent in search of a new route are subject to split horizon rules just as messages advertising new or changing network information.
EIGRP Feasibility Condition
Feasibility condition is used to select loop-free backup paths. A path entry is considered not feasible if the advertised distance is equal to or greater than the feasible distance of the lowest metric path. EIGRP uses the feasibility condition to prevent the formation of routing loops. This is used in addition to split horizon.
The feasibility condition follows this sequence of steps during path selection:
Step 1: Find the best path i.e. the path with the lowest metric; take the metric of the best path as as X.
Step 2: Find all alternate backup paths to the same network and retrieve the metric reported by the neighbor; any one path with a metric reported by the neighbor that is less than X is close to the destination.
Step 3: Exclude all other paths with a metric reported by the neighbor greater than or equal to X.
- Sub-second convergence when primary path fails. Cisco has indicated in some documentation that the time interval between failure of the successor and installation of the feasible successor to the RIB is 200ms.
- Fault isolation
- Unequal-cost load balancing.
Feasibility Condition Terminology
Successor: best path to a destination with the lowest feasible distance.
Feasible Distance (FD): Composite metric of the best path (successor).
Reported Distance (RD): Composite metric learned from the neighbor.
Feasibile Successor (FS): Backup paths that meet the feasibility condition.
Once the best path is chosen, additional paths are examined for backup routes. The FC finds loop-free backup routes using the logic: if RD is less than FD, path is loop-free and viable backup. Paths that meet FC are feasible successors(FS). Only FS can be used for unequal cost load balancing.
The command show ip eigrp topology only displays successors and feasible successors i.e. paths that meet
the feasibility condition. To display all paths including those that fail the feasibility condition, append the keyword
all-links to the command.
R8#show ip eigrp topology all-links
EIGRP-IPv4 VR(EIGRP_8) Topology Table for AS(1)/ID(8.8.8.8)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
r - reply Status, s - sia Status
P 10.7.12.0/24, 1 successors, FD is 1392640, serno 12
via 10.100.0.2 (1392640/163840), GigabitEthernet0/0
via 10.100.1.1 (13844480/1392640), FastEthernet4/1
via 10.100.1.2 (13189120/163840), FastEthernet4/1
P 10.8.11.0/24, 1 successors, FD is 163840, serno 2
via Connected, Loopback11
P 10.3.10.0/24, 1 successors, FD is 330956800, serno 42
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.2 (343408640/330956800), FastEthernet4/1
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 192.168.101.0/24, 1 successors, FD is 14713889, serno 57
via 10.100.0.1 (14713889/14058529), GigabitEthernet0/0
via 10.100.1.2 (23592960/14713889), FastEthernet4/1
via 10.100.1.1 (22937600/14058529), FastEthernet4/1
via 10.100.1.4 (22282240/13403169), FastEthernet4/1
P 10.3.12.128/25, 1 successors, FD is 330956800, serno 45
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.2 (343408640/330956800), FastEthernet4/1
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 10.200.23.0/30, 1 successors, FD is 14417920, serno 28
via 10.100.0.1 (14417920/13762560), GigabitEthernet0/0
via 10.100.1.1 (20316160/13762560), FastEthernet4/1
via 10.100.1.2 (20971520/14417920), FastEthernet4/1
via 10.100.1.4 (19660800/13107200), FastEthernet4/1
P 10.200.13.0/30, 1 successors, FD is 3276800, serno 36
via 10.100.0.1 (3276800/2621440), GigabitEthernet0/0
via 10.100.1.2 (15728640/3276800), FastEthernet4/1
via 10.100.1.4 (14417920/1966080), FastEthernet4/1
via 10.100.1.1 (15073280/2621440), FastEthernet4/1
P 10.7.10.0/24, 1 successors, FD is 1392640, serno 10
via 10.100.0.2 (1392640/163840), GigabitEthernet0/0
via 10.100.1.1 (13844480/1392640), FastEthernet4/1
via 10.100.1.2 (13189120/163840), FastEthernet4/1
P 192.168.100.0/24, 1 successors, FD is 14713889, serno 56
via 10.100.0.1 (14713889/14058529), GigabitEthernet0/0
via 10.100.1.2 (23592960/14713889), FastEthernet4/1
via 10.100.1.1 (22937600/14058529), FastEthernet4/1
via 10.100.1.4 (22282240/13403169), FastEthernet4/1
P 10.200.34.0/30, 1 successors, FD is 3932160, serno 46
via 10.100.0.1 (3932160/3276800), GigabitEthernet0/0
via 10.100.1.2 (16384000/3932160), FastEthernet4/1
via 10.100.1.4 (15073280/2621440), FastEthernet4/1
via 10.100.1.1 (15728640/3276800), FastEthernet4/1
P 10.8.12.0/24, 1 successors, FD is 163840, serno 3
via Connected, Loopback12
P 10.0.16.0/30, 1 successors, FD is 13762560, serno 25
via 10.100.0.1 (13762560/13107200), GigabitEthernet0/0
via 10.100.1.1 (19660800/13107200), FastEthernet4/1
via 10.100.1.2 (20316160/13762560), FastEthernet4/1
P 10.3.12.0/25, 1 successors, FD is 330956800, serno 44
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.2 (343408640/330956800), FastEthernet4/1
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 10.100.0.0/29, 1 successors, FD is 1310720, serno 4
via Connected, GigabitEthernet0/0
via 10.100.1.1 (13762560/1310720), FastEthernet4/1
via 10.100.1.2 (13762560/1310720), FastEthernet4/1
P 10.3.11.0/24, 1 successors, FD is 330956800, serno 43
via 10.100.0.1 (330956800/330301440), GigabitEthernet0/0
via 10.100.1.2 (343408640/330956800), FastEthernet4/1
via 10.100.1.4 (342097920/329646080), FastEthernet4/1
via 10.100.1.1 (342753280/330301440), FastEthernet4/1
P 10.100.68.0/24, 1 successors, FD is 13107200, serno 6
via Connected, FastEthernet4/0
P 10.7.11.0/24, 1 successors, FD is 1392640, serno 11
via 10.100.0.2 (1392640/163840), GigabitEthernet0/0
via 10.100.1.1 (13844480/1392640), FastEthernet4/1
via 10.100.1.2 (13189120/163840), FastEthernet4/1
P 10.8.10.0/24, 1 successors, FD is 163840, serno 1
via Connected, Loopback10
P 10.200.45.0/30, 1 successors, FD is 14058529, serno 51
via 10.100.0.1 (14058529/13403169), GigabitEthernet0/0
via 10.100.1.2 (22937600/14058529), FastEthernet4/1
via 10.100.1.4 (21626880/12747809), FastEthernet4/1
via 10.100.1.1 (22282240/13403169), FastEthernet4/1
P 10.100.1.0/29, 1 successors, FD is 13107200, serno 5
via Connected, FastEthernet4/1
via 10.100.0.1 (13762560/13107200), GigabitEthernet0/0
via 10.100.0.2 (13762560/13107200), GigabitEthernet0/0
P 10.0.26.0/30, 1 successors, FD is 1966080, serno 26
via 10.100.0.1 (1966080/1310720), GigabitEthernet0/0
via 10.100.1.1 (13762560/1310720), FastEthernet4/1
via 10.100.1.4 (13762560/1310720), FastEthernet4/1
via 10.100.1.2 (14417920/1966080), FastEthernet4/1
P 10.0.12.0/30, 1 successors, FD is 2621440, serno 27
via 10.100.0.1 (2621440/1966080), GigabitEthernet0/0
via 10.100.1.1 (14417920/1966080), FastEthernet4/1
via 10.100.1.2 (15073280/2621440), FastEthernet4/1
via 10.100.1.4 (13762560/1310720), FastEthernet4/1
R8#
The parameters of the composite metric that DUAL uses for metric calculation can be viewed for individual routes. To view
the details of a path, append the network address of interest to the command show ip eigrp topology
as shown in the
following output.
R8#show ip eigrp topology 10.7.12.0
EIGRP-IPv4 VR(EIGRP_8) Topology Entry for AS(1)/ID(8.8.8.8)
%Entry 10.7.12.0/8 not in topology table
R8#show ip eigrp topology 10.7.12.0/24
EIGRP-IPv4 VR(EIGRP_8) Topology Entry for AS(1)/ID(8.8.8.8) for 10.7.12.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1392640, RIB is 10880
Descriptor Blocks:
10.100.0.2 (GigabitEthernet0/0), from 10.100.0.2, Send flag is 0x0
Composite metric is (1392640/163840), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 11250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 7.7.7.7
10.100.1.1 (FastEthernet4/1), from 10.100.1.1, Send flag is 0x0
Composite metric is (13844480/1392640), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 111250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 7.7.7.7
10.100.1.2 (FastEthernet4/1), from 10.100.1.2, Send flag is 0x0
Composite metric is (13189120/163840), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 101250000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 1
Originating router is 7.7.7.7
R8#
From the preceeding output, the following observations can be made about the path to the network 10.7.12.0:
- Successor: the successor is the path via the neighbor at IP 10.100.0.2.
- Exit Interface: the exit interface to the successor is GigabitEthernet0/0
- Feasible Distance: has the metric 1392640
- Reported Distance: has metric 163840
- Feasible Successor: is the path to the neighbor at IP 10.100.1.2
- EIGRP includes the RID of the device that originally advertised the network i.e. the device that injected the route into EIGRP; in this case it is the device with RID 7.7.7.7
- EIGRP indicates that the route is in a passive state i.e. no alternate route is being searched for
- The route is an internal route i.e. it was not redistributed into EIGRP. As previously mentioned, EIGRP uses TLVs included in the update packets to differentiate between internal and external routes.
Additional information about the successor route can be obtained from the routing table and the output of the
show ip protocols command.
R8#show ip route 10.7.12.0
Routing entry for 10.7.12.0/24
Known via "eigrp 1", distance 90, metric 10880, type internal
Redistributing via eigrp 1
Last update from 10.100.0.2 on GigabitEthernet0/0, 00:21:40 ago
Routing Descriptor Blocks:
* 10.100.0.2, from 10.100.0.2, 00:21:40 ago, via GigabitEthernet0/0
Route metric is 10880, traffic share count is 1
Total delay is 12 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 1
R8#
R8#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_8) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 8.8.8.8
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 22
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.0.3/32
10.100.1.0/30
10.100.68.2/32
Routing Information Sources:
Gateway Distance Last Update
10.100.1.4 90 00:36:07
10.100.0.2 90 00:36:07
10.100.1.2 90 00:36:07
10.100.1.1 90 00:36:07
10.100.0.1 90 00:36:07
Distance: internal 90 external 170
R8#
From the EIGRP topology table as shown in the previous output, the successor to the network 10.7.12.0/24 has a feasible distance of 1392640 which is the path through neighbor 10.100.0.2. However, from the topology table and routing table, the metric is reported as 10,880. The metric 10880 in the routing table is calculated using the formulae
32-bit metric = 64-bit metric × (1 ÷ RIB-scale value)
The RIB-scale value is 128 as shown in the output of the command
show ip protocols.
Therefore the 32-bit metric calculated as:
32-bit metric = 1392640 × (1 ÷ 128)
32-bit metric = 10880 It is important to note that EIGRP is currently using only one path for the destination 10.7.12.0/24. EIGRP is capable of using multiple paths to route traffic to a destination. Optimizing EIGRP to utilise multiple paths including unequal cost paths is covered under Traffic Engineering section.
Reconvergence and Failure Detection
When EIGRP detects that it has lost its successor for a network, a reconvergence process starts to identify an alternate path to the network. The reconvergence process differs for paths with a feasible successor from paths without a feasible successor.
Paths without a feasible successor
Loss of a successor results in a route going into the Active state. DUAL must perform a new route calculation. The route state changes from passive (P) to active (A) in the EIGRP topology table. The router detecting the topology change sends out Query packets to all neighbors except through the interface to the successor.
- If a neighbor does not have any other neighbors, it sends a reply packet indicating that the route does not exist.
- If the query came from the successor for the route, the receiving router detects the delay set for infinity,
sets the prefix as active in the EIGRP topology, and sends out a query packet to all downstream EIGRP neighbors for
that route.
The query process continues from router to router until a router establishes the query boundary. A query boundary is established when a router does not mark the prefix as active, meaning that it responds to a query as follows: It says it does not have a route to the prefix or it replies with EIGRP attributes because the query did not come from the successor.
- If the query did not come from the successor for that route, it detects that the delay is set for infinity but ignores it because it did not come from the successor. The receiving router replies with the EIGRP attributes for that route.
Paths without a feasible successor can be viewed using the command:
show ip eigrp topology zero-successors.
Paths with a feasible successor
- Loss of successor does not make a route go into the Active state. The device receiving the query sends a Reply with the appropriate EIGRP attributes.
- Feasible successor is instantly promoted to successor.
- Result is sub-second convergence.
Stuck in Active
EIGRP maintains a timer called “active timer” which has a default value of 3 minutes (180 seconds). If a route is lost and a feasible successor is not available in the topology table, the local device sends a query packet. EIGRP waits half of the active timer value (90 seconds) for a reply to this query. If the router does not receive a response within 90 seconds, the originating router sends a stuck in active (SIA) query to EIGRP neighbors that did not respond.
Upon receipt of an SIA query, the router should respond within 90 seconds with an SIA reply. An SIA reply contains the route information or provides information on the query process itself. If a router fails to respond to an SIA query by the time the active timer expires, EIGRP deems the router SIA. If the SIA state is declared for a neighbor, DUAL deletes all routes from that neighbor, treating the situation as if the neighbor responded with unreachable message for all routes.
You can only troubleshoot active EIGRP prefixes when the router is waiting for a reply.
Prefixes with active queries can be viewed with the command show ip eigrp topology.
The SIA timer value can be verified from the output of the
command show ip protocols.
Configuration of SIA Timers
The active timer is set to 3 minutes by default.
The active timer can be disabled or modified with the command
timers active-time {disabled | 1-65535-minutes} under the EIGRP process.
With classic configuration mode, the command runs directly under the EIGRP process, and with named-mode configuration,
the command runs under the topology base.
R7(config)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 7.7.7.7
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 20
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.7.0.0/16
10.100.1.0/28
10.100.1.16/28
Routing Information Sources:
Gateway Distance Last Update
10.100.1.8 90 00:00:06
10.100.1.6 90 00:00:06
10.100.1.20 90 00:00:06
10.100.1.19 90 00:00:06
10.100.1.17 90 00:00:06
Distance: internal 90 external 170
R7(config)#
R7(config)#router eigrp EIGRP_NAMED
*Oct 12 10:13:46.271: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.8 (GigabitEthernet0/0) is resync: peer graceful-restart
R7(config)#router eigrp EIGRP_NAMED
R7(config-router)#address-family ipv4 unicast autonomous-system 1
R7(config-router-af)#topology base
R7(config-router-af-topology)#timers active-time ?
<1-65535> active state time limit in minutes
disabled disable time limit for active state
R7(config-router-af-topology)#timers active-time 2
R7(config-router-af-topology)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 7.7.7.7
Topology : 0 (base)
Active Timer: 2 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 20
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.7.0.0/16
10.100.1.0/28
10.100.1.16/28
Routing Information Sources:
Gateway Distance Last Update
10.100.1.8 90 00:01:34
10.100.1.6 90 00:01:50
10.100.1.20 90 00:01:50
10.100.1.19 90 00:01:50
10.100.1.17 90 00:01:50
Distance: internal 90 external 170
R7(config-router-af-topology)#
EIGRP Verification
The operational state of EIGRP can be verified by the following commands:
show ip protocolsshow ip eigrp interfacesshow ip route eigrpshow ip eigrp neighbor
show ip protocols
A great deal of information on how EIGRP was configured and its current operational state can be learned from the output of the
command show ip protocols
R8#show ip protocol
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is (route-map) RM_DENY_19216800
Incoming routes in GigabitEthernet0/0 will have 7000000 added to metric if on list ACL_10200340
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 10.8.14.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 26
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.1.16/28
10.100.0.0/23
Routing Information Sources:
Gateway Distance Last Update
10.100.1.7 90 00:16:47
10.100.1.6 90 00:16:47
10.100.1.20 90 00:16:47
10.100.1.18 90 00:16:47
10.100.1.17 90 00:16:47
Distance: internal 90 external 170
R8#
The following can be learned from the output of the command show ip protocols
- Autonomous System number: is one (1).
- EIGRP configuration mode: is named-mode as it has K6 among its K-values.
- Filters:
- filtering is being applied on inbound routes with a route map named RM_DENY_19216800 applied to
all interfaces (using
af-interface defaultcommand). - an offset-list is modifying the metric of all routes that permitted in access control list ACL_10200340 and is applied to all inbound routes entering interface GigabitEthernet0/0.
- filtering is being applied on inbound routes with a route map named RM_DENY_19216800 applied to
all interfaces (using
- K-Values are at their default values of K1=1, K3=1 and K2=0, K4=0, K5=0, K6=0
- Metric RIB-scale value is 128.
- Router ID of local device is 10.8.14.1
- Active timer value is 3 mins
- Administrative Distance values are at defaults of 90 (internal) and 170 (external/redistributed routes)
- Maximum Path for load balancing is at default of four (4).
- Variance multiplier is at default of one (1) for equal-cost load balancing. Unequal cost load balancing is currently disabled.
- Prefix Count of prefixes learned through EIGRP from neighbors is 26.
- Total Redist Count the device is not implementing redistribution hence count is zero (0).
- Automatic summarization is currently disabled (default).
- Maximum hop count supported is 100.
- Routing for Networks: local device is advertising the following networks: 10.8.0.0/16, 10.100.1.16/28, 10.100.0.0/23
- Routing Information Sources device has formed neighborships with five (5) devices.
show ip eigrp interfaces
After configuration of EIGRP or during troubleshooting, it is a good practice to
verify that only the intended interfaces are running EIGRP and the expected
networks are being advertised by EIGRP.
The command show ip eigrp interfaces [{interface-id [detail] | detail}]
shows active EIGRP interfaces.
R6#show ip eigrp interfaces
EIGRP-IPv4 VR(EIGRP_R6) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa3/0 1 0/0 0/0 60 0/0 264 0
Gi0/0 2 0/0 0/0 82 0/0 168 0
Fa3/1 3 0/0 0/0 95 0/1 248 0
Gi1/0 1 0/0 0/0 91 0/0 384 0
Lo10 0 0/0 0/0 0 0/0 0 0
Lo11 0 0/0 0/0 0 0/0 0 0
Lo12 0 0/0 0/0 0 0/0 0 0
R6#
The columns of the command show ip eigrp interfaces are explained below;
| Interface: | Interfaces on which EIGRP is enabled on. |
| Peers: | Number of EIGRP neighborships formed through that interface. |
| Xmt Queue Un/Reliable: |
Total number of packets waiting in transport transmission queue; reliable (requiring acknowledgement) and unreliable (no acknowledgement required). A value of zero indicates that the network is stable and the interface does not have packets in its transmit buffer. |
| Mean SRTT: | Calculated smooth round-trip time (SRTT) for packets that were transmitted to and received from all neighbors on the interface. |
| Multicast Flow Timer: | The multicast flow control timer value (in milliseconds) for the interface |
| Pending Routes: | Number of routes in the transmit queue that need to be sent. |
Appending the optional detail keyword provides additional information, such as the authentication status
(whether it is configured or not), EIGRP timers, split horizon, and various packet counts.
R6#show ip eigrp interface detail
EIGRP-IPv4 VR(EIGRP_R6) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa3/0 1 0/0 0/0 60 0/0 264 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 6/0
Hello's sent/expedited: 650/2
Un/reliable mcasts: 0/6 Un/reliable ucasts: 7/2
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 2
Topology-ids on interface - 0
Authentication mode is not set
Gi0/0 2 0/0 0/0 82 0/0 168 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 9/1
Hello's sent/expedited: 653/3
Un/reliable mcasts: 0/9 Un/reliable ucasts: 13/5
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 1
Topology-ids on interface - 0
Authentication mode is not set
Fa3/1 3 0/0 0/0 95 0/1 248 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 14/1
Hello's sent/expedited: 650/4
Un/reliable mcasts: 0/12 Un/reliable ucasts: 26/10
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 0
Retransmissions sent: 4 Out-of-sequence rcvd: 2
Topology-ids on interface - 0
Authentication mode is not set
Gi1/0 1 0/0 0/0 91 0/0 384 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 10/0
Hello's sent/expedited: 368/2
Un/reliable mcasts: 0/10 Un/reliable ucasts: 11/3
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 1
Topology-ids on interface - 0
Authentication mode is not set
NOTE: The show ip eigrp interfaces command does not
display passive interfaces and intefaces that are administratively shutdown. With classic-mode,
the command show ip protocols does not display interfaces that are operating in EIGRP passive-mode
that were configured using the command passive-interface default.
show ip interface <interface>
It is also possible to determine the interfaces participating in EIGRP using the command
show ip interface. This can be done by viewing the
multicast groups that the interface has joined. As previously mentioned, EIGRP
sends multicast packets to 224.0.0.10.
The command show ip interface <interface-id> can confirm
the interface multicast address that the
interface has joined.
R6#show ip interface g1/0
GigabitEthernet1/0 is up, line protocol is up
Internet address is 10.0.26.2/30
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Multicast reserved groups joined: 224.0.0.10
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is enabled
Local Proxy ARP is disabled
Security level is default
Split horizon is enabled
ICMP redirects are always sent
ICMP unreachables are always sent
ICMP mask replies are never sent
IP fast switching is enabled
IP fast switching on the same interface is disabled
IP Flow switching is disabled
IP CEF switching is enabled
IP CEF switching turbo vector
IP CEF turbo switching turbo vector
IP multicast fast switching is enabled
IP multicast distributed fast switching is disabled
IP route-cache flags are Fast, CEF
Router Discovery is disabled
IP output packet accounting is disabled
IP access violation accounting is disabled
TCP/IP header compression is disabled
RTP/IP header compression is disabled
Policy routing is disabled
Network address translation is disabled
BGP Policy Mapping is disabled
Input features: MCI Check
IPv4 WCCP Redirect outbound is disabled
IPv4 WCCP Redirect inbound is disabled
IPv4 WCCP Redirect exclude is disabled
R6#
You can view all interfaces on a device participating in EIGRP by filtering the output of the
show ip interface as shown in the following code snippet.
R6#show ip interface | in up|reserved
GigabitEthernet0/0 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
GigabitEthernet1/0 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
FastEthernet3/0 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
FastEthernet3/1 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
Loopback10 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
Loopback11 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
Loopback12 is up, line protocol is up
Multicast reserved groups joined: 224.0.0.10
Verify EIGRP Transport
To view real-time EIGRP packet transmission and receipt, the commanddebug
eigrp packet hello | ack | update | query | reply can be used.
R8#debug eigrp packet ?
SIAquery EIGRP SIA-Query packets
SIAreply EIGRP SIA-Reply packets
ack EIGRP ack packets
hello EIGRP hello packets
ipxsap EIGRP ipxsap packets
query EIGRP query packets
reply EIGRP reply packets
request EIGRP request packets
retry EIGRP retransmissions
stub EIGRP stub packets
terse Display all EIGRP packets except Hellos
update EIGRP update packets
verbose Display all EIGRP packets
<cr>
R8#debug eigrp packet
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on
R8#
*Oct 1 20:17:16.779: EIGRP: Received HELLO on Gi0/0 - paklen 20 nbr 10.100.0.1
*Oct 1 20:17:16.783: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:17:16.787: {type = 1, length = 12}
*Oct 1 20:17:16.787: {vector = {
*Oct 1 20:17:16.787: {01000100 0000000F}
*Oct 1 20:17:16.799: }
*Oct 1 20:17:16.799: {type = 4, length = 8}
*Oct 1 20:17:16.803: {vector = {
*Oct 1 20:17:16.803: {0A000200}
*Oct 1 20:17:16.811: }
*Oct 1 20:17:17.191: EIGRP: Sending HELLO on Fa4/1 - paklen 20
*Oct 1 20:17:17.191: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
R8#
*Oct 1 20:17:17.195: {type = 1, length = 12}
*Oct 1 20:17:17.195: {vector = {
*Oct 1 20:17:17.199: {01000100 0000000F}
*Oct 1 20:17:17.207: }
*Oct 1 20:17:17.211: {type = 4, length = 8}
*Oct 1 20:17:17.211: {vector = {
*Oct 1 20:17:17.211: {0A000200}
*Oct 1 20:17:17.211: }
*Oct 1 20:17:17.967: EIGRP: Received HELLO on Fa4/1 - paklen 20 nbr 10.100.1.1
*Oct 1 20:17:17.971: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:17:17.971: {type = 1, length = 12}
*Oct 1 20:17:17.975: {vector = {
*Oct 1 20:17:17.975: {01000100 0000000F}
*Oct 1 20:17:17.987: }
R8#
*Oct 1 20:17:17.987: {type = 4, length = 8}
*Oct 1 20:17:17.987: {vector = {
*Oct 1 20:17:17.991: {0A000200}
*Oct 1 20:17:17.995: }
*Oct 1 20:17:17.999: EIGRP: Received HELLO on Fa4/1 - paklen 20 nbr 10.100.1.2
*Oct 1 20:17:17.999: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:17:18.003: {type = 1, length = 12}
*Oct 1 20:17:18.003: {vector = {
*Oct 1 20:17:18.007: {01000100 0000000F}
*Oct 1 20:17:18.015: }
*Oct 1 20:17:18.019: {type = 4, length = 8}
*Oct 1 20:17:18.019: {vector = {
*Oct 1 20:17:18.019: {0A000200}
*Oct 1 20:17:18.027: }
R8#
*Oct 1 20:17:19.831: EIGRP: Sending HELLO on Gi0/0 - paklen 20
*Oct 1 20:17:19.831: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Oct 1 20:17:19.835: {type = 1, length = 12}
*Oct 1 20:17:19.835: {vector = {
*Oct 1 20:17:19.839: {01000100 0000000F}
*Oct 1 20:17:19.847: }
*Oct 1 20:17:19.851: {type = 4, length = 8}
*Oct 1 20:17:19.851: {vector = {
*Oct 1 20:17:19.851: {0A000200}
*Oct 1 20:17:19.859: }
*Oct 1 20:17:20.695: EIGRP: Sending HELLO on Fa4/0 - paklen 20
*Oct 1 20:17:20.695: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Oct 1 20:17:20.699: {type = 1, length = 12}
R8#
Sometimes, Hello packets can get in the way of troubleshooting using the command
debug eigrp packets. To filter out Hello packets
from the debug output, append the terse keyword.
R8#debug eigrp packets terse ?
SIAquery EIGRP SIA-Query packets
SIAreply EIGRP SIA-Reply packets
ack EIGRP ack packets
hello EIGRP hello packets
ipxsap EIGRP ipxsap packets
query EIGRP query packets
reply EIGRP reply packets
request EIGRP request packets
retry EIGRP retransmissions
stub EIGRP stub packets
terse Display all EIGRP packets except Hellos
update EIGRP update packets
verbose Display all EIGRP packets
<cr>
R8#debug eigrp packets terse
(UPDATE, REQUEST, QUERY, REPLY, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on
R8#
*Oct 1 20:18:54.011: EIGRP: Received UPDATE on Gi0/0 - paklen 45 nbr 10.100.0.2
*Oct 1 20:18:54.011: AS 1, Flags 0x0:(NULL), Seq 26/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:18:54.015: {type = 602, length = 45}
*Oct 1 20:18:54.015: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.015: {routerid = 1.1.1.1
*Oct 1 20:18:54.015: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.015: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:54.015: delay = 120000000, bw = 100000,
*Oct 1 20:18:54.015: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.015: {nh:00000000}
*Oct 1 20:18:54.015: {1E0AC80D 00}
*Oct 1 20:18:54.015: }
*Oct 1 20:18:54.015: EIGRP: Enqueueing ACK on Gi0/0 - paklen 0 nbr 10.100.0.2 tid 0
*Oct 1 20:18:54.015: Ack seq 26 iidbQ un/rely 0/0 peerQ un/rely 1/0 route: 10.200.13.0/30
*Oct 1 20:18:54.019: EIGRP: Recei
R8#ved UPDATE on Fa4/1 - paklen 90 nbr 10.100.1.4
*Oct 1 20:18:54.023: AS 1, Flags 0x0:(NULL), Seq 29/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:18:54.027: {type = 602, length = 45}
*Oct 1 20:18:54.027: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.031: {routerid = 1.1.1.1
*Oct 1 20:18:54.031: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.031: mtu = {1500:[00, 05, DC]), hopcount = 1,
*Oct 1 20:18:54.035: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:54.035: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.035: {nh:00000000}
*Oct 1 20:18:54.043: {1E0A0010 00}
*Oct 1 20:18:54.051: }
*Oct 1 20:18:54.051: {type = 602, length = 45}
*Oct 1 20:18:54.051: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.055: {routerid = 1.1.1.1
*Oct 1 20:18:54.055: {offset = 0, priority = 0, reliability = 255, load
R8# = 1,
*Oct 1 20:18:54.059: mtu = {1500:[00, 05, DC]), hopcount = 1,
*Oct 1 20:18:54.059: delay = 20000000, bw = 1000000,
*Oct 1 20:18:54.059: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.063: {nh:00000000}
*Oct 1 20:18:54.067: {1E0AC80D 00}
*Oct 1 20:18:54.075: }
*Oct 1 20:18:54.079: EIGRP: Enqueueing ACK on Fa4/1 - paklen 0 nbr 10.100.1.4 tid 0
*Oct 1 20:18:54.083: Ack seq 29 iidbQ un/rely 0/0 peerQ un/rely 1/0 route: 10.0.16.0/30 route: 10.200.13.0/30
*Oct 1 20:18:54.095: EIGRP: Received UPDATE on Fa4/1 - paklen 45 nbr 10.100.1.2
*Oct 1 20:18:54.095: AS 1, Flags 0x0:(NULL), Seq 27/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:18:54.099: {type = 602, length = 45}
*Oct 1 20:18:54.103: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.103: {routerid = 1.1.1.1
*Oct 1 20:18:54.107: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 2
R8#0:18:54.107: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:54.107: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:54.111: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.111: {nh:00000000}
*Oct 1 20:18:54.119: {1E0AC80D 00}
*Oct 1 20:18:54.123: }
*Oct 1 20:18:54.123: EIGRP: Enqueueing ACK on Fa4/1 - paklen 0 nbr 10.100.1.2 tid 0
*Oct 1 20:18:54.123: Ack seq 27 iidbQ un/rely 0/0 peerQ un/rely 1/0 route: 10.200.13.0/30
*Oct 1 20:18:54.123: EIGRP: Sending ACK on Gi0/0 - paklen 0 nbr 10.100.0.2 tid 0
*Oct 1 20:18:54.127: AS 1, Flags 0x0:(NULL), Seq 0/26 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 1 20:18:54.131: EIGRP: Sending ACK on Fa4/1 - paklen 0 nbr 10.100.1.4 tid 0
*Oct 1 20:18:54.135: AS 1, Flags 0x0:(NULL), Seq 0/29 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 1 20:18:54.143: EIGRP: Sending ACK on Fa4/1 - paklen 0 nbr 10.100.1.2 tid 0
*Oct 1 20:18:
R8#54.143: AS 1, Flags 0x0:(NULL), Seq 0/27 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/0
*Oct 1 20:18:54.151: EIGRP: Enqueueing UPDATE on Fa4/1 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 35-35
*Oct 1 20:18:54.155: EIGRP: Sending UPDATE on Fa4/1 - paklen 45 tid 0
*Oct 1 20:18:54.159: AS 1, Flags 0x0:(NULL), Seq 30/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 35-35
*Oct 1 20:18:54.163: {type = 602, length = 45}
*Oct 1 20:18:54.163: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.163: {routerid = 1.1.1.1
*Oct 1 20:18:54.167: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.167: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:54.171: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:54.171: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.171: {nh:00000000}
*Oct 1 20:18:54.179: {1E0AC80D 00}
*Oct 1 20:18:54.187: }
*Oct 1 20:18:54.187: EIGRP
R8#: Enqueueing UPDATE on Gi0/0 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 35-35
*Oct 1 20:18:54.203: EIGRP: Sending UPDATE on Gi0/0 - paklen 45 tid 0
*Oct 1 20:18:54.203: AS 1, Flags 0x0:(NULL), Seq 31/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 35-35
*Oct 1 20:18:54.207: {type = 602, length = 45}
*Oct 1 20:18:54.207: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.211: {routerid = 1.1.1.1
*Oct 1 20:18:54.211: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.215: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:54.215: delay = 120000000, bw = 100000,
*Oct 1 20:18:54.215: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.219: {nh:00000000}
*Oct 1 20:18:54.223: {1E0AC80D 00}
*Oct 1 20:18:54.231: }
*Oct 1 20:18:54.239: EIGRP: Received ACK on Fa4/1 - paklen 0 nbr 10.100.1.4
*Oct 1 20:18:54.239: AS 1, Flags 0x0:(NULL), Seq 0/30 interfaceQ 0/0 iidbQ
R8# un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.243: EIGRP: Received ACK on Fa4/1 - paklen 0 nbr 10.100.1.2
*Oct 1 20:18:54.247: AS 1, Flags 0x0:(NULL), Seq 0/30 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.343: EIGRP: Received ACK on Gi0/0 - paklen 0 nbr 10.100.0.2
*Oct 1 20:18:54.347: AS 1, Flags 0x0:(NULL), Seq 0/31 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.467: EIGRP: Received UPDATE on Gi0/0 - paklen 45 nbr 10.100.0.1
*Oct 1 20:18:54.471: AS 1, Flags 0x0:(NULL), Seq 20/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.475: {type = 602, length = 45}
*Oct 1 20:18:54.475: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.479: {routerid = 1.1.1.1
*Oct 1 20:18:54.479: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.479: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:54.483: delay = 30000000, bw = 1000000,
*Oct
R8# 1 20:18:54.483: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.487: {nh:00000000}
*Oct 1 20:18:54.495: {1E0AC80D 00}
*Oct 1 20:18:54.503: }
*Oct 1 20:18:54.503: EIGRP: Enqueueing ACK on Gi0/0 - paklen 0 nbr 10.100.0.1 tid 0
*Oct 1 20:18:54.507: Ack seq 20 iidbQ un/rely 0/0 peerQ un/rely 1/1 route: 10.200.13.0/30
*Oct 1 20:18:54.519: EIGRP: Received ACK on Gi0/0 - paklen 0 nbr 10.100.0.1
*Oct 1 20:18:54.519: AS 1, Flags 0x0:(NULL), Seq 0/31 interfaceQ 1/0 iidbQ un/rely 0/0 peerQ un/rely 1/1
*Oct 1 20:18:54.519: EIGRP: GigabitEthernet0/0 multicast flow blocking cleared
*Oct 1 20:18:54.519: EIGRP: Enqueueing UPDATE on Gi0/0 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 36-36
*Oct 1 20:18:54.519: EIGRP: Sending ACK on Gi0/0 - paklen 0 nbr 10.100.0.1 tid 0
*Oct 1 20:18:54.519: AS 1, Flags 0x0:(NULL), Seq 0/20 interfaceQ 1/0 iidbQ un/rely 0/1 peerQ un/rely 1/0
*Oct 1 20:18:54.519: EIGRP: Received UPDATE on Gi0/0 - paklen 45
R8# nbr 10.100.0.2
*Oct 1 20:18:54.519: AS 1, Flags 0x0:(NULL), Seq 28/0 interfaceQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Oct 1 20:18:54.519: {type = 602, length = 45}
*Oct 1 20:18:54.519: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.519: {routerid = 1.1.1.1
*Oct 1 20:18:54.519: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.519: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:54.519: delay = 281474976710655, bw = 1000000,
*Oct 1 20:18:54.519: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.519: {nh:00000000}
*Oct 1 20:18:54.519: {1E0AC80D 00}
*Oct 1 20:18:54.519: }
*Oct 1 20:18:54.519: EIGRP: Enqueueing ACK on Gi0/0 - paklen 0 nbr 10.100.0.2 tid 0
*Oct 1 20:18:54.519: Ack seq 28 iidbQ un/rely 0/1 peerQ un/rely 1/0 route: 10.200.13.0/30
*Oct 1 20:18:54.519: EIGRP: Received UPDATE on Fa4/1 - paklen 45 nbr 10.100.1.1
*Oct 1 20:1
R8#8:54.519: AS 1, Flags 0x0:(NULL), Seq 19/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.519: {type = 602, length = 45}
*Oct 1 20:18:54.519: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.519: {routerid = 1.1.1.1
*Oct 1 20:18:54.519: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.519: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:54.519: delay = 30000000, bw = 1000000,
*Oct 1 20:18:54.519: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.519: {nh:00000000}
*Oct 1 20:18:54.519: {1E0AC80D 00}
*Oct 1 20:18:54.519: }
*Oct 1 20:18:54.519: EIGRP: Enqueueing ACK on Fa4/1 - paklen 0 nbr 10.100.1.1 tid 0
*Oct 1 20:18:54.519: Ack seq 19 iidbQ un/rely 0/0 peerQ un/rely 1/1 route: 10.200.13.0/30
*Oct 1 20:18:54.519: EIGRP: Received ACK on Fa4/1 - paklen 0 nbr 10.100.1.1
*Oct 1 20:18:54.519: AS 1, Flags 0x0:(NULL), Seq
R8#0/30 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/1
*Oct 1 20:18:54.519: EIGRP: FastEthernet4/1 multicast flow blocking cleared
*Oct 1 20:18:54.519: EIGRP: Enqueueing UPDATE on Fa4/1 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 36-36
*Oct 1 20:18:54.519: EIGRP: Sending ACK on Fa4/1 - paklen 0 nbr 10.100.1.1 tid 0
*Oct 1 20:18:54.519: AS 1, Flags 0x0:(NULL), Seq 0/19 interfaceQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 1/0
*Oct 1 20:18:54.523: EIGRP: Received UPDATE on Fa4/1 - paklen 45 nbr 10.100.1.2
*Oct 1 20:18:54.527: AS 1, Flags 0x0:(NULL), Seq 29/0 interfaceQ 0/0 iidbQ un/rely 0/1 peerQ un/rely 0/0
*Oct 1 20:18:54.531: {type = 602, length = 45}
*Oct 1 20:18:54.531: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.531: {routerid = 1.1.1.1
*Oct 1 20:18:54.535: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.535: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:54.539: delay = 40000
R8#000, bw = 1000000,
*Oct 1 20:18:54.539: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.539: {nh:00000000}
*Oct 1 20:18:54.547: {1E0AC80D 00}
*Oct 1 20:18:54.555: }
*Oct 1 20:18:54.555: EIGRP: Enqueueing ACK on Fa4/1 - paklen 0 nbr 10.100.1.2 tid 0
*Oct 1 20:18:54.559: Ack seq 29 iidbQ un/rely 0/1 peerQ un/rely 1/0 route: 10.200.13.0/30
*Oct 1 20:18:54.567: EIGRP: Sending UPDATE on Gi0/0 - paklen 45 tid 0
*Oct 1 20:18:54.567: AS 1, Flags 0x0:(NULL), Seq 32/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 36-36
*Oct 1 20:18:54.567: {type = 602, length = 45}
*Oct 1 20:18:54.567: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.567: {routerid = 1.1.1.1
*Oct 1 20:18:54.567: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.567: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:54.567: delay = 281474976710655, bw = 1000000,
*Oct 1 20:18:54.567:
R8# reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.567: {nh:00000000}
*Oct 1 20:18:54.567: {1E0AC80D 00}
*Oct 1 20:18:54.567: }
*Oct 1 20:18:54.567: EIGRP: Sending UPDATE on Fa4/1 - paklen 45 tid 0
*Oct 1 20:18:54.567: AS 1, Flags 0x0:(NULL), Seq 33/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 36-36
*Oct 1 20:18:54.567: {type = 602, length = 45}
*Oct 1 20:18:54.567: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:54.567: {routerid = 1.1.1.1
*Oct 1 20:18:54.567: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:54.567: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:54.567: delay = 40000000, bw = 1000000,
*Oct 1 20:18:54.567: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:54.567: {nh:00000000}
*Oct 1 20:18:54.571: {1E0AC80D 00}
*Oct 1 20:18:54.579: }
*Oct 1 20:18:54.579: EIGRP: Sending ACK on Gi0/0 - paklen 0 n
R8#br 10.100.0.2 tid 0
*Oct 1 20:18:54.579: AS 1, Flags 0x0:(NULL), Seq 0/28 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/1
*Oct 1 20:18:54.583: EIGRP: Sending ACK on Fa4/1 - paklen 0 nbr 10.100.1.2 tid 0
*Oct 1 20:18:54.583: AS 1, Flags 0x0:(NULL), Seq 0/29 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 1/1
*Oct 1 20:18:54.595: EIGRP: Received ACK on Gi0/0 - paklen 0 nbr 10.100.0.2
*Oct 1 20:18:54.595: AS 1, Flags 0x0:(NULL), Seq 0/32 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.603: EIGRP: Received ACK on Fa4/1 - paklen 0 nbr 10.100.1.4
*Oct 1 20:18:54.603: AS 1, Flags 0x0:(NULL), Seq 0/33 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.607: EIGRP: Received ACK on Fa4/1 - paklen 0 nbr 10.100.1.2
*Oct 1 20:18:54.611: AS 1, Flags 0x0:(NULL), Seq 0/33 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.627: EIGRP: Received ACK on Gi0/0 - paklen 0 nbr 10.100.0.1
*Oct 1 20:18:54.631: AS 1, Flags 0x
R8#0:(NULL), Seq 0/32 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.635: EIGRP: GigabitEthernet0/0 multicast flow blocking cleared
*Oct 1 20:18:54.635: EIGRP: Received ACK on Fa4/1 - paklen 0 nbr 10.100.1.1
*Oct 1 20:18:54.635: AS 1, Flags 0x0:(NULL), Seq 0/33 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:54.635: EIGRP: FastEthernet4/1 multicast flow blocking cleared
*Oct 1 20:18:56.495: EIGRP: Received UPDATE on Fa4/1 - paklen 223 nbr 10.100.1.4
*Oct 1 20:18:56.499: AS 1, Flags 0x0:(NULL), Seq 32/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 1 20:18:56.499: {type = 602, length = 44}
*Oct 1 20:18:56.503: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.503: {routerid = 3.3.3.3
*Oct 1 20:18:56.507: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.507: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:56.507: delay = 5020000000, bw = 1
R8#000000,
*Oct 1 20:18:56.511: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.511: {nh:00000000}
*Oct 1 20:18:56.519: {180A030A}
*Oct 1 20:18:56.523: }
*Oct 1 20:18:56.523: {type = 602, length = 44}
*Oct 1 20:18:56.527: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.527: {routerid = 3.3.3.3
*Oct 1 20:18:56.531: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.531: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:56.531: delay = 5020000000, bw = 1000000,
*Oct 1 20:18:56.535: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.535: {nh:00000000}
*Oct 1 20:18:56.543: {180A030B}
*Oct 1 20:18:56.547: }
*Oct 1 20:18:56.547: {type = 602, length = 45}
*Oct 1 20:18:56.551: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.551: {routerid = 3.3.3.3
*Oct 1 20:18:56.555: {offset = 0,
R8#priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.555: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:56.555: delay = 5020000000, bw = 1000000,
*Oct 1 20:18:56.559: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.559: {nh:00000000}
*Oct 1 20:18:56.567: {190A030C 00}
*Oct 1 20:18:56.575: }
*Oct 1 20:18:56.575: {type = 602, length = 45}
*Oct 1 20:18:56.575: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.579: {routerid = 3.3.3.3
*Oct 1 20:18:56.579: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.579: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:56.583: delay = 5020000000, bw = 1000000,
*Oct 1 20:18:56.583: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.587: {nh:00000000}
*Oct 1 20:18:56.591: {190A030C 80}
*Oct 1 20:18:56.599: }
*Oct 1 20:18:56.5
R8#99: {type = 602, length = 45}
*Oct 1 20:18:56.603: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.603: {routerid = 3.3.3.3
*Oct 1 20:18:56.607: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.607: mtu = {1500:[00, 05, DC]), hopcount = 2,
*Oct 1 20:18:56.607: delay = 30000000, bw = 1000000,
*Oct 1 20:18:56.611: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.611: {nh:00000000}
*Oct 1 20:18:56.619: {1E0AC822 00}
*Oct 1 20:18:56.627: }
*Oct 1 20:18:56.627: EIGRP: Enqueueing ACK on Fa4/1 - paklen 0 nbr 10.100.1.4 tid 0
*Oct 1 20:18:56.631: Ack seq 32 iidbQ un/rely 0/0 peerQ un/rely 1/0 route: 10.3.10.0/24 route: 10.3.11.0/24
route: 10.3.12.0/25 route: 10.3.12.128/25 route: 10.200.34.0/30
*Oct 1 20:18:56.667: EIGRP: Sending ACK on Fa4/1 - paklen 0 nbr 10.100.1.4 tid 0
*Oct 1 20:18:56.667: AS 1, Flags 0x0:(NULL), Seq 0/32 interfaceQ 0/0 iidbQ un
R8#/rely 0/0 peerQ un/rely 1/0
*Oct 1 20:18:56.703: EIGRP: Enqueueing UPDATE on Fa4/1 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 37-41
*Oct 1 20:18:56.711: EIGRP: Sending UPDATE on Fa4/1 - paklen 223 tid 0
*Oct 1 20:18:56.715: AS 1, Flags 0x0:(NULL), Seq 34/0 interfaceQ 2/0 iidbQ un/rely 0/0 serno 37-41
*Oct 1 20:18:56.719: {type = 602, length = 44}
*Oct 1 20:18:56.719: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.723: {routerid = 3.3.3.3
*Oct 1 20:18:56.723: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.727: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.727: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.727: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.731: {nh:00000000}
*Oct 1 20:18:56.735: {180A030A}
*Oct 1 20:18:56.743: }
*Oct 1 20:18:56.743: {type = 602, length = 44}
*Oct 1 20:18:56.743: {vector = {afi = 1,
R8#tid = 0}
*Oct 1 20:18:56.747: {routerid = 3.3.3.3
*Oct 1 20:18:56.747: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.751: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.751: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.751: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.755: {nh:00000000}
*Oct 1 20:18:56.759: {180A030B}
*Oct 1 20:18:56.767: }
*Oct 1 20:18:56.767: {type = 602, length = 45}
*Oct 1 20:18:56.767: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.771: {routerid = 3.3.3.3
*Oct 1 20:18:56.771: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.775: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.775: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.775: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.779:
R8# {nh:00000000}
*Oct 1 20:18:56.783: {190A030C 00}
*Oct 1 20:18:56.791: }
*Oct 1 20:18:56.795: {type = 602, length = 45}
*Oct 1 20:18:56.795: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.799: {routerid = 3.3.3.3
*Oct 1 20:18:56.799: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.799: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.803: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.803: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.803: {nh:00000000}
*Oct 1 20:18:56.811: {190A030C 80}
*Oct 1 20:18:56.819: }
*Oct 1 20:18:56.819: {type = 602, length = 45}
*Oct 1 20:18:56.823: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.823: {routerid = 3.3.3.3
*Oct 1 20:18:56.823: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.827: mtu = {1500:[00,
R8# 05, DC]), hopcount = 3,
*Oct 1 20:18:56.827: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.831: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.831: {nh:00000000}
*Oct 1 20:18:56.835: {1E0AC822 00}
*Oct 1 20:18:56.843: }
*Oct 1 20:18:56.847: EIGRP: Enqueueing UPDATE on Gi0/0 - paklen 0 tid 0 iidbQ un/rely 0/1 serno 37-41
*Oct 1 20:18:56.855: EIGRP: Sending UPDATE on Gi0/0 - paklen 223 tid 0
*Oct 1 20:18:56.859: AS 1, Flags 0x0:(NULL), Seq 35/0 interfaceQ 2/0 iidbQ un/rely 0/0 serno 37-41
*Oct 1 20:18:56.863: {type = 602, length = 44}
*Oct 1 20:18:56.863: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.863: {routerid = 3.3.3.3
*Oct 1 20:18:56.867: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.867: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.867: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.867
R8#: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.871: {nh:00000000}
*Oct 1 20:18:56.871: {180A030A}
*Oct 1 20:18:56.875: }
*Oct 1 20:18:56.879: {type = 602, length = 44}
*Oct 1 20:18:56.879: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.879: {routerid = 3.3.3.3
*Oct 1 20:18:56.879: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.883: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.883: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.883: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.883: {nh:00000000}
*Oct 1 20:18:56.887: {180A030B}
*Oct 1 20:18:56.891: }
*Oct 1 20:18:56.891: {type = 602, length = 45}
*Oct 1 20:18:56.895: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.895: {routerid = 3.3.3.3
*Oct 1 20:18:56.895: {offset = 0, priority = 0, reliability
R8# = 255, load = 1,
*Oct 1 20:18:56.903: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.903: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.907: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.907: {nh:00000000}
*Oct 1 20:18:56.911: {190A030C 00}
*Oct 1 20:18:56.915: }
*Oct 1 20:18:56.915: {type = 602, length = 45}
*Oct 1 20:18:56.915: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.919: {routerid = 3.3.3.3
*Oct 1 20:18:56.919: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.919: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.919: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.923: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.923: {nh:00000000}
*Oct 1 20:18:56.927: {190A030C 80}
*Oct 1 20:18:56.931: }
*Oct 1 20:18:56.931: {type = 602
R8#, length = 45}
*Oct 1 20:18:56.931: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:56.935: {routerid = 3.3.3.3
*Oct 1 20:18:56.935: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:56.935: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:56.939: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:56.939: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:56.939: {nh:00000000}
*Oct 1 20:18:56.943: {1E0AC822 00}
*Oct 1 20:18:56.947: }
*Oct 1 20:18:57.023: EIGRP: Received UPDATE on Gi0/0 - paklen 223 nbr 10.100.0.2
*Oct 1 20:18:57.027: AS 1, Flags 0x0:(NULL), Seq 31/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/1
*Oct 1 20:18:57.031: {type = 602, length = 44}
*Oct 1 20:18:57.031: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:57.035: {routerid = 3.3.3.3
*Oct 1 20:18:57.035: {offset = 0, priority = 0, reliability = 255, load
R8# = 1,
*Oct 1 20:18:57.035: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:57.039: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:57.039: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:57.043: {nh:00000000}
*Oct 1 20:18:57.047: {180A030A}
*Oct 1 20:18:57.051: }
*Oct 1 20:18:57.051: {type = 602, length = 44}
*Oct 1 20:18:57.051: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:57.055: {routerid = 3.3.3.3
*Oct 1 20:18:57.055: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:57.055: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:57.059: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:57.059: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:57.059: {nh:00000000}
*Oct 1 20:18:57.063: {180A030B}
*Oct 1 20:18:57.067: }
*Oct 1 20:18:57.067: {type = 602, length = 45}
*O
R8#ct 1 20:18:57.067: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:57.071: {routerid = 3.3.3.3
*Oct 1 20:18:57.071: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:57.071: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:57.071: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:57.075: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:57.075: {nh:00000000}
*Oct 1 20:18:57.079: {190A030C 00}
*Oct 1 20:18:57.083: }
*Oct 1 20:18:57.083: {type = 602, length = 45}
*Oct 1 20:18:57.083: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:57.087: {routerid = 3.3.3.3
*Oct 1 20:18:57.087: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:57.087: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:57.091: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:57.091: reserved = 00, o
R8#paque_flags = 00}
*Oct 1 20:18:57.091: {nh:00000000}
*Oct 1 20:18:57.095: {190A030C 80}
*Oct 1 20:18:57.099: }
*Oct 1 20:18:57.099: {type = 602, length = 45}
*Oct 1 20:18:57.103: {vector = {afi = 1, tid = 0}
*Oct 1 20:18:57.103: {routerid = 3.3.3.3
*Oct 1 20:18:57.103: {offset = 0, priority = 0, reliability = 255, load = 1,
*Oct 1 20:18:57.107: mtu = {1500:[00, 05, DC]), hopcount = 3,
*Oct 1 20:18:57.107: delay = 281474976710655, bw = 100000,
*Oct 1 20:18:57.107: reserved = 00, opaque_flags = 00}
*Oct 1 20:18:57.107: {nh:00000000}
*Oct 1 20:18:57.111: {1E0AC822 00}
*Oct 1 20:18:57.115: }
R8#
EIGRP Routes in Routing Table
EIGRP routes that are installed into the RIB can be viewed using the command show ip route eigrp.
EIGRP routes originating within the autonomous system have an administrative distance (AD) of 90 and are
shown in the routing table with the code 'D'.
Routes that originate from outside the autonomous system are external EIGRP routes.
External EIGRP routes have an AD of 170 and are shown in the routing table with the code 'D EX'.
Placing external EIGRP routes into the RIB with a higher AD acts as a loop-prevention mechanism.
R3#show ip route eigrp
Codes: L - local, C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 26 subnets, 5 masks
D 10.0.12.0/30 [90/3072] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.0.16.0/30 [90/28416] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.0.26.0/30 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.7.10.0/24 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.7.11.0/24 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.7.12.0/24 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.8.10.0/24 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.8.11.0/24 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.8.12.0/24 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.100.0.0/29 [90/28672] via 10.200.23.1, 01:39:48, FastEthernet3/0
[90/28672] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.100.1.0/29 [90/3328] via 10.200.13.1, 01:39:48, GigabitEthernet1/0
D 10.200.45.0/30
[90/19200] via 10.200.34.2, 00:24:08, GigabitEthernet0/0
D EX 192.168.100.0/24
[170/19456] via 10.200.34.2, 00:24:08, GigabitEthernet0/0
D EX 192.168.101.0/24
[170/19456] via 10.200.34.2, 00:24:08, GigabitEthernet0/0
R3#
The metric for the selected route is the second number in square brackets.
Detailed information can be learned about a path in the routing table such as the source of the routing information,
metrics and additional information from the source that offered the path to the routing table. These details can be
viewed by running the command show ip route <network-address>
R3#show ip route 10.8.1.0
% Subnet not in table
R3#show ip route 10.8.10.0
Routing entry for 10.8.10.0/24
Known via "eigrp 1", distance 90, metric 3328, type internal
Redistributing via eigrp 1
Last update from 10.200.13.1 on GigabitEthernet1/0, 00:02:42 ago
Routing Descriptor Blocks:
* 10.200.13.1, from 10.200.13.1, 00:02:42 ago, via GigabitEthernet1/0
Route metric is 3328, traffic share count is 1
Total delay is 32 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
R3#
R3#show ip route 10.100.0.0
Routing entry for 10.100.0.0/29
Known via "eigrp 1", distance 90, metric 28672, type internal
Redistributing via eigrp 1
Last update from 10.200.13.1 on GigabitEthernet1/0, 00:02:55 ago
Routing Descriptor Blocks:
* 10.200.23.1, from 10.200.23.1, 00:02:55 ago, via FastEthernet3/0
Route metric is 28672, traffic share count is 1
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
10.200.13.1, from 10.200.13.1, 00:02:55 ago, via GigabitEthernet1/0
Route metric is 28672, traffic share count is 1
Total delay is 120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
R3#
R3#show ip route 192.168.100.0
Routing entry for 192.168.100.0/24
Known via "eigrp 1", distance 170, metric 19456, type external
Redistributing via eigrp 1
Last update from 10.200.34.2 on GigabitEthernet0/0, 00:21:32 ago
Routing Descriptor Blocks:
* 10.200.34.2, from 10.200.34.2, 00:21:32 ago, via GigabitEthernet0/0
Route metric is 19456, traffic share count is 1
Total delay is 120 microseconds, minimum bandwidth is 155000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
R3#
EIGRP Optimization
While the default EIGRP configurations work, some changes to EIGRP default behaviour improves its performance and provides additional security to the network.
EIGRP Timers
EIGRP supports two different timers: Hello interval and Hold timer. Hello interval controls how often hello packets are sent. Hello packets are used:
- To discover new neighbors
- Act as a keepalive messages
- Communicate K-values and hold-timer value.
- Acknowledge other packet types when reliability is important.
Hello interval, by default, is 5 seconds. Hold-timer is often set to three times the hello timer i.e. 15 seconds. Neighbors not receiving hello packets within the hold timer interval will be considered down. EIGRP will remove the neighbor from its table and try to determine how to reach the destination that the neighbor advertised.
To verify hello interval and hold timer values, issue the command show ip eigrp interface detail
R6#show ip eigrp interface detail
EIGRP-IPv4 VR(EIGRP_R6) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa3/0 1 0/0 0/0 60 0/0 264 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 6/0
Hello's sent/expedited: 650/2
Un/reliable mcasts: 0/6 Un/reliable ucasts: 7/2
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 2
Topology-ids on interface - 0
Authentication mode is not set
Gi0/0 2 0/0 0/0 82 0/0 168 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 9/1
Hello's sent/expedited: 653/3
Un/reliable mcasts: 0/9 Un/reliable ucasts: 13/5
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 2 Out-of-sequence rcvd: 1
Topology-ids on interface - 0
Authentication mode is not set
Modification of EIGRP Timer Values
Hello interval and Hold timers do not have to match between neighbors but should not be over-skewed otherwise flapping occurs.
In named-mode, the EIGRP timer values can be changed using the command
af-interface <interface-id>
or af-interface default.
The following command changes the hello-interval to 4 seconds and hold-time to 8 seconds. Changing the hello interval
does not automatically change the hold-timer to three-times the hello-interval. You have to make the change manually.
The hello-interval and hold-timer values can be in the range 1 - 65535 seconds.
R7#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R7(config)#
R7(config)#router eigrp EIGRP_R7
R7(config-router)#address-family ipv4 unicast autonomous-system 1
R7(config-router-af)#af-interface gigabitethernet0/0
R7(config-router-af-interface)#hello-interval 4
R7(config-router-af-interface)#hold-time 8
R7(config-router-af-interface)#do show ip eigrp interface detail g0/0
EIGRP-IPv4 VR(EIGRP_R7) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 2 0/0 0/0 96 0/0 328 0
Hello-interval is 4, Hold-time is 8
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 25/1
Hello's sent/expedited: 3034/5
Un/reliable mcasts: 0/18 Un/reliable ucasts: 44/15
Mcast exceptions: 1 CR packets: 1 ACKs suppressed: 4
Retransmissions sent: 2 Out-of-sequence rcvd: 8
Topology-ids on interface - 0
Authentication mode is not set
R7(config-router-af-interface)#
For classic-mode, the timer values are configured in interface configuration mode.
R3#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R3(config)#
R3(config)#interface fastethernet3/0
R3(config-if)#ip hello-interval eigrp 1 4
R3(config-if)#ip hold-time eigrp 1 8
R3(config-if)#
For faster detection of neighbor failures or link-failures, a more optimum solution would be to leave the EIGRP timer values at their defaults and configure Bi-Directional Forwarding (BFD).
BFD
In EIGRP named mode, BFD is configured under the af-interface mode:
R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
R6(config-router-af-interface)#
If BFD is configured under af-interface default, all interfaces with EIGRP peers will be registered to
receive BFD notifications. However, remember that BFD has to first be configured on the interface otherwise the
following error message will be generated:
R6(config)#router eigrp EIGRP_NAMED
R6(config-router)#address-family ipv4 autonomous-system 1
R6(config-router-af)#af-interface gigabitethernet0/0
R6(config-router-af-interface)#bfd
%EIGRP: BFD interval is not configured on interface GigabitEthernet0/0 required for BFD operation.
R6(config-router-af-interface)#
In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on link failure on a single interface as below:
R6(config)#router eigrp 2
R6(config-router)#bfd interface gigabitethernet 0/0
In EIGRP classic mode, EIGRP can be configured to receive BFD notifications on all EIGRP-enabled interfaces as below:
R6(config)#router eigrp 2
R6(config-router)#bfd all-interfaces
NOTE: Configuration of EIGRP to receive notifications from all EIGRP enabled interfaces as demonstrated above does not issue a log message if BFD has not been enabled on the interface using the interface-mode BFD configuration commands.
Passive Interfaces
Passive interfaces in EIGRP allow the network configured on an interface to be advertised but prevent neighbor adjacencies from forming on those interfaces because hello packets are not sent. Hello packets received on passive interfaces are not processed.
Configuration of passive interfaces can be good from a security perspective. As Hello packets are not sent out passive interfaces, a packet sniffer will not be able to view routing information off of these interfaces.
To configure an EIGRP interface as passive, you use the command passive-interface <interface-id> under the EIGRP process
for classic configuration.
R3(config)#router eigrp 1
R3(config-router)#passive-interface gigabitethernet1/0
R3(config-router)#
*Sep 26 23:56:23.779: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.200.13.1 (GigabitEthernet1/0) is down: interface passive
R3(config-router)#
For named-mode configuration, the passive-interface is configured under the af-interface default command for all EIGRP
interfaces or on a specific interface with the af-interface <interface-id>.
R8(config-router)#address-family ipv4 unicast autonomous-system 1
R8(config-router-af)#
R8(config-router-af)#
R8(config-router-af)#do show ip eigrp neighbor fastethernet4/0
EIGRP-IPv4 VR(EIGRP_8) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
5 10.100.68.1 Fa4/0 12 00:02:08 64 384 0 41
R8(config-router-af)#
R8(config-router-af)#af-interface fastethernet4/0
R8(config-router-af-interface)#passive-interface
R8(config-router-af-interface)#
*Sep 22 23:38:36.623: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.68.1 (FastEthernet4/0) is down: interface passive
R8(config-router-af-interface)#
R8(config-router-af-interface)#do show ip eigrp neighbor fastethernet4/0
EIGRP-IPv4 VR(EIGRP_8) Address-Family Neighbors for AS(1)
Verification of Passive-Interfaces
The presence of passive interfaces can be confirmed by issuing the privileged mode command:
show ip protocols
R8(config-router-af-interface)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_8) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 8.8.8.8
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 22
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.0.3/32
10.100.1.0/30
10.100.68.2/32
Passive Interface(s):
FastEthernet4/0
Routing Information Sources:
Gateway Distance Last Update
10.100.68.1 90 00:04:01
10.100.1.4 90 00:04:01
10.100.0.2 90 00:04:01
10.100.1.2 90 00:04:01
10.100.1.1 90 00:04:01
10.100.0.1 90 00:04:01
Distance: internal 90 external 170
R8(config-router-af-interface)#
R8(config-router-af-interface)#do show ip eigrp interface
EIGRP-IPv4 VR(EIGRP_8) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Lo10 0 0/0 0/0 0 0/0 0 0
Lo11 0 0/0 0/0 0 0/0 0 0
Lo12 0 0/0 0/0 0 0/0 0 0
Gi0/0 2 0/0 0/0 81 0/0 312 0
Fa4/1 3 0/0 0/0 65 0/0 248 0
R8(config-router-af-interface)#
Passive interfaces do not show up under the output of the show ip eigrp interfaces command. This
command displays interfaces that are actively sending and processing EIGRP Hello packets.
EIGRP Summarization
Summarization is commonly used to limit routing table size by aggregating multiple routes into a single or few prefixes with shorter prefix length. This is usually done at a network convergence point such as distribution and core layers.
Some benefits of summarization include the following:
- Shrinking the routing table of all the routers in the EIGRP autonomous system.
- Creates a query boundary and shrinks the query domain when a route goes active during convergence, thereby reducing SIA scenarios.
In older EIGRP versions, automatic summarization at classful boundaries was the default setting. In updated versions of EIGRP, IOS v15.0, automatic summarization has been disabled.
In the event of path loss, EIGRP is able to achieve sub-second convergence using feasible successors (FS). FS are pre-calculated backup routes which pass the feasibility condition. If no backup routes are available in the topology table, query messages are sent out to all EIGRP neighbors. Convergence of the network becomes a function of the query domain size. A query domain can be bounded by summarization and stub route advertisement.
EIGRP query packets are generated when a route becomes active due to link-loss, loss of an EIGRP neighbor, change of path metric. Query packets are sent for an exact match of the lost route for example do you have a route to 1.2.3.4/24. Reply is immediately sent if no match is available for example 1.2.3.4/24 does not match my 1.0.0.0/8. This is how summaries limit the query domain.
EIGRP supports two ways of configuring summarization: auto-summarization and manual summarization. EIGRP hierarchy is arbitrary unlike OSPF that supports a two-tier hierarchy. Summaries can be configured in any part of the network. However, it is recommended to configure summarization at network convergence points such as core layer or distribution layer of a two-tier/three-tier network topology.
EIGRP supports auto-summarization where networks are summarized at classful network address boundaries.
If a network design implements Variable Length Subnet Mask IP address allocation,
then auto-summarization needs to be
disabled. Auto-summary is disabled in newer IOS versions.
It can be enabled with auto-summary command at the
process-level in classic EIGRP and base topology in named EIGRP.
Manual summarization is supported at any bit boundary including 0.0.0.0/0. It
automatically suppresses subnet advertisements.
It is still possible to advertise constituent subnets even after configuring
summarization using a leak-map. Manual summarization can be implemented; in
classic-mode under interface configuration mode
using the command ip summary-address eigrp. In named-mode manual summarization is configured under the
af-interface mode: summary-address.
Note: In named-mode, manual summarization can not be configured under the default interface.
Other Uses of Summarization
- Limits individual route knowledge.
- Limits query range:
- Limits the number of networks to be individually processed for example core devices do not need to know details of the access layer networks. Here, access-layer summarization can be done at the distribution layer.
- Limits query scope; if a summarizing router receives a query for a specific route that is a subnet of the summary, it replies indicating that it does not have an available route and does not send a query out for the route.
- Traffic Engineering: In networks with redundant links, summarization can be used to control the interfaces over which network ranges can be accessed. This can be done by advertising those specific summary addresses over particular interfaces and suppressing the advertisement of the component routes over other interfaces. Additionally, more specific summaries can be advertised over one interface and less specific addresses can be advertised over another interface. As routers will prefer the more specific route, the path through interface A will be preferred over the path through interface B regardless of the metric. Interface B will become a feasible successor.
EIGRP Summarization Metrics
The summarizing router uses the lowest metric of the component routes in the summary aggregate prefix. The path metric for the summary aggregate is based on the path attributes of the path with the lowest metric.
Every time a matching component route for the summary aggregate is added or removed, EIGRP must verify that the summary
route is still using the attributes from the path with the lowest metric.
The fluctuation in the path metric is resolved by configuring a static metric for
the summary route with the command
summary-metric <network> {/<prefix-length> | <subnet-mask>} <bandwidth> <delay> <reliability> <load> <MTU> <administrative_distance>.
The metric is statically defined per summary in the topology base configuration mode for named EIGRP and under router
eigrp process mode for classic EIGRP.
Automatic Summarization
EIGRP supports automatic summarization, automatically summarizing network advertisements when they cross a classful network boundary.
Configuration of EIGRP Summarization
EIGRP summaries are configured on the EIGRP-enabled interfaces. EIGRP summarizes network prefixes on an interface-by-interface basis. A summary aggregate is configured for the EIGRP interface. The summary aggregate prefix is not advertised until a prefix matches it. Interface-specific summarization can be performed in any section of the network topology. Configuration of summary routes should be done on the outgoing interface.
Classic Mode
In classic-mode, EIGRP summary is configured using the interface mode command
ip summary-address eigrp <as> <network> <subnet-mask> [leak-map <route-map-name>].
The leak-map option allows the advertisement of the component routes of the
summary route identified in the route map.
The following configuration shows the routing table of a downstream device R8 before and after the configuration of summarization on device R3.
R8#show ip route eigrp | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 36 subnets, 7 masks
D 10.0.12.0/30 [90/20480] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 10.0.16.0/30 [90/107520] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 10.0.26.0/30 [90/15360] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 10.3.10.0/24
[90/2585600] via 10.100.0.1, 00:00:08, GigabitEthernet0/0
D 10.3.11.0/24
[90/2585600] via 10.100.0.1, 00:00:08, GigabitEthernet0/0
D 10.3.12.0/25
[90/2585600] via 10.100.0.1, 00:00:08, GigabitEthernet0/0
D 10.3.12.128/25
[90/2585600] via 10.100.0.1, 00:00:08, GigabitEthernet0/0
D 10.7.10.0/24 [90/10880] via 10.100.0.2, 01:04:56, GigabitEthernet0/0
D 10.7.11.0/24 [90/10880] via 10.100.0.2, 01:04:56, GigabitEthernet0/0
D 10.7.12.0/24 [90/10880] via 10.100.0.2, 01:04:56, GigabitEthernet0/0
D 10.8.0.0/16 is a summary, 01:03:36, Null0
D 10.8.0.0/19 is a summary, 00:33:46, Null0
D 10.200.13.0/30
[90/25600] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 10.200.23.0/30
[90/112640] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 10.200.34.0/30
[90/30720] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 10.200.45.0/30
[90/109832] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
D 192.168.96.0/20 [90/114952] via 10.100.0.1, 01:04:56, GigabitEthernet0/0
R3(config-router)#interface g1/0
R3(config-if)#ip summary-address eigrp 1 10.3.8.0 255.255.248.0
R3(config-if)#interface fastethernet3/0
R3(config-if)#ip summary-address eigrp 1 10.3.8.0 255.255.248.0
R8#show ip route eigrp | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 33 subnets, 7 masks
D 10.0.12.0/30 [90/20480] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 10.0.16.0/30 [90/107520] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 10.0.26.0/30 [90/15360] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 10.3.8.0/21 [90/2585600] via 10.100.0.1, 00:01:07, GigabitEthernet0/0
D 10.7.10.0/24 [90/10880] via 10.100.0.2, 01:03:11, GigabitEthernet0/0
D 10.7.11.0/24 [90/10880] via 10.100.0.2, 01:03:11, GigabitEthernet0/0
D 10.7.12.0/24 [90/10880] via 10.100.0.2, 01:03:11, GigabitEthernet0/0
D 10.8.0.0/16 is a summary, 01:01:51, Null0
D 10.8.0.0/19 is a summary, 00:32:01, Null0
D 10.200.13.0/30
[90/25600] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 10.200.23.0/30
[90/112640] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 10.200.34.0/30
[90/30720] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 10.200.45.0/30
[90/109832] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
D 192.168.96.0/20 [90/114952] via 10.100.0.1, 01:03:11, GigabitEthernet0/0
EIGRP summarization is configured on interface GigabitEthernet1/0 and FastEthernet3/0 to suppress the sending of component routes on both interfaces.
Named Mode
In named EIGRP mode, the summary address command is configured under the af-inteface mode.
Note that summarization can not be configured under the default interface configuration mode.
The af-interface default option cannot be used with the
summary-address command. It requires the use of a specific interface.
R8(config-router-af-interface)#af-interface fastethernet4/0
R8(config-router-af-interface)#summary-address 10.8.0.0 255.255.0.0
R8(config-router-af-interface)#af-interface fastethernet4/1
R8(config-router-af-interface)#summary-address 10.8.0.0 255.255.0.0
On a downstream router, summarization can be verified by viewing the routes in the routing table:
R3#show ip route eigrp | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 26 subnets, 7 masks
D 10.0.12.0/30 [90/3072] via 10.200.13.1, 00:52:29, GigabitEthernet1/0
D 10.0.16.0/30 [90/28416] via 10.200.13.1, 00:52:29, GigabitEthernet1/0
D 10.0.26.0/30 [90/3328] via 10.200.13.1, 00:52:29, GigabitEthernet1/0
D 10.7.10.0/24 [90/3328] via 10.200.13.1, 00:43:00, GigabitEthernet1/0
D 10.7.11.0/24 [90/3328] via 10.200.13.1, 00:43:00, GigabitEthernet1/0
D 10.7.12.0/24 [90/3328] via 10.200.13.1, 00:43:00, GigabitEthernet1/0
D 10.8.0.0/16 [90/3584] via 10.200.13.1, 00:18:20, GigabitEthernet1/0
D 10.8.0.0/19 [90/3328] via 10.200.13.1, 00:13:17, GigabitEthernet1/0
D 10.100.0.0/29 [90/28672] via 10.200.23.1, 00:52:29, FastEthernet3/0
[90/28672] via 10.200.13.1, 00:52:29, GigabitEthernet1/0
D 10.100.1.0/29 [90/3328] via 10.200.13.1, 00:52:29, GigabitEthernet1/0
D 10.100.68.0/24
[90/28928] via 10.200.13.1, 00:47:23, GigabitEthernet1/0
D 10.200.45.0/30
[90/19200] via 10.200.34.2, 00:52:26, GigabitEthernet0/0
D 192.168.96.0/20 [90/19456] via 10.200.34.2, 00:45:17, GigabitEthernet0/0
R3#
It is important to note that if redistribution is implemented on a network and route summarization is not configured on the redistributing router but instead the external routes are summarized by a downstream router, routers receiving the summary address of the redistributed routes will consider the summary address as an internal route.
When implementing summarization, EIGRP poisons component routes of the summary; the summarizing router sends updates of the component routes with the delay parameter set to infinity. In some cases, the bandwidth is also set to maximum value of 4294967295
Discard Route
EIGRP adds a discard route to the routing table of the router where summarization is configured. This route has an exit interface Null0. It is added to avoid routing loops. If a packet matches the summary address range but no specific entry exists in the routing table to match that packet, it is forwarded to the Null0 interface i.e. it is discarded.
R4(config)#interface gigabitethernet0/0
R4(config-if)#ip summary-address eigrp 1 192.168.96.0 255.255.240.0
R4(config-if)#do show ip route | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 22 subnets, 5 masks
D 10.0.12.0/30 [90/3328] via 10.200.34.1, 00:18:35, GigabitEthernet0/0
D 10.0.16.0/30 [90/28672] via 10.200.34.1, 00:18:35, GigabitEthernet0/0
D 10.0.26.0/30 [90/3584] via 10.200.34.1, 00:18:35, GigabitEthernet0/0
D 10.3.10.0/24
[90/130816] via 10.200.34.1, 00:18:37, GigabitEthernet0/0
......
L 10.200.45.1/32 is directly connected, POS5/0
D 192.168.96.0/20 is a summary, 00:06:03, Null0
D EX 192.168.100.0/24 [170/19200] via 10.200.45.2, 00:15:45, POS5/0
D EX 192.168.101.0/24 [170/19200] via 10.200.45.2, 00:15:45, POS5/0
192.168.102.0/24 is subnetted, 1 subnets
D EX 192.168.102.0 [170/19200] via 10.200.45.2, 00:09:06, POS5/0
R4(config-if)#
EIGRP installs a discard route on the summarizing routers as a routing loop prevention mechanism.
A discard route is a route that matches the summary aggregate prefix with the destination Null0. This prevents routing loops where portions of the summarized network range do not have a more specific entry in the Routing Information Base (RIB) on the summarizing router.
The AD for the Null0 route is 5 by default. You view the discard route by using the
command show ip route <network> <subnet-mask>.
R3(config-if)#do show ip route 10.3.8.0 255.255.248.0
Routing entry for 10.3.8.0/21
Known via "eigrp 1", distance 5, metric 128256, type internal
Redistributing via eigrp 1
Routing Descriptor Blocks:
* directly connected, via Null0
Route metric is 128256, traffic share count is 1
Total delay is 5000 microseconds, minimum bandwidth is 8000000 Kbit
Reliability 255/255, minimum MTU 1514 bytes
Loading 1/255, Hops 0
R3(config-if)#
EIGRP Leak-maps
Leak-maps allow selective advertisement of selected component subnets of a summary route. They can be used for longest match traffic engineering. Leak-maps are applied through a route-map.
The following is the default behaviour if an incomplete configuration is entered:
- If the referenced route-map is not existent, then the leak-map has no effect.
- If the route-map references a non-existent access-list, the summary address and all its component routes are advertised.
- If the route-map referenced by the leak-map does not reference an access-list, the summary address and all its component routes are advertised.
Verification of Summarization
Summarization can be verified using the command show ip protocols:
R8(config-router-af-interface)#do show ip proto
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_8) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 8.8.8.8
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 27
Total Redist Count: 0
Automatic Summarization: disabled
Address Summarization:
10.8.0.0/19 for Fa4/1
Summarizing 7 components with metric 163840
10.8.0.0/16 for Gi0/0, Fa4/0
Summarizing 8 components with metric 163840
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.0.3/32
10.100.1.0/30
10.100.68.2/32
Routing Information Sources:
Gateway Distance Last Update
10.100.1.4 90 00:01:18
10.100.0.2 90 00:31:08
10.100.1.2 90 00:01:18
10.100.1.1 90 00:01:18
10.100.0.1 90 00:31:08
Distance: internal 90 external 170
R8(config-router-af-interface)#
EIGRP Stub
An EIGRP stub router does not advertise routes that it learns from other EIGRP peers. By default, EIGRP stubs advertise only connected and summary routes, but they can be configured so that they only receive routes or advertise any combination of redistributed routes, connected routes, or summary routes.
When configured on the spoke router, the router announces its stub router status using a new TLV in the EIGRP Hello messages. The following is an EIGRP Hello Packet capture from an EIGRP stub device that advertises connected, redistributed routes and routes permitted via a leak-map.
⊳ Frame 6: 80 bytes on wire (640 bits), 80 bytes captured (640 bits) on interface -, id 0
⊳ Ethernet II, Src: ca:04:04:59:00:08 (ca:04:04:59:00:08), Dst: IPv4mcast_0a (01:00:5e:00:00:0a)
⊳ Internet Protocol Version 4, Src: 10.200.34.2, Dst: 224.0.0.10
⋄ Cisco EIGRP
Version: 2
Opcode: Hello (5)
Checksum: 0xefac [correct]
[Checksum Status: Good]
Flags: 0x00000000
.... .... .... .... .... .... .... ...0 = Init: Not set
.... .... .... .... .... .... .... ..0. = Conditional Receive: Not set
.... .... .... .... .... .... .... .0.. = Restart: Not set
.... .... .... .... .... .... .... 0... = End Of Table: Not set
Sequence: 0
Acknowledge: 0
Virtual Router ID: 0 (Address-Family)
Autonomous System: 1
Parameters
Type: Parameters (0x0001)
Length: 12
K1: 1
K2: 0
K3: 1
K4: 0
K5: 0
K6: 0
Hold Time: 15
Software Version: EIGRP=10.0, TLV=2.0
Type: Software Version (0x0004)
Length: 8
EIGRP Release: 10.00
EIGRP TLV version: 2.00
Peer Stub Information
Type: Peer Stub Information (0x0006)
Length: 6
Stub Options: 0x0019, Connected, Redistributed, Leak-Map
.... .... .... ...1 = Connected: Set
.... .... .... ..0. = Static: Not set
.... .... .... .0.. = Summary: Not set
.... .... .... 1... = Redistributed: Set
.... .... ...1 .... = Leak-Map: Set
.... .... ..0. .... = Receive-Only: Not set
EIGRP stub feature was developed mainly for use with hub and spoke deployments; it is often seen in networks with branches and a connecting WAN. In hub and spoke topologies, the spokes are the devices on which EIGRP stub is configured. Unlike OSPF, EIGRP does not change behavior based on the media type of an interface. Serial and Ethernet interfaces are treated the same.
The EIGRP stub routing feature improves network stability, reduces resource utilization, and simplifies the stub device configuration on the spoke. However, due to bandwidth constraints particularly with WAN links, some WAN topologies may require special consideration for bandwidth utilization, split horizon, or next-hop self. Stub feature can help reduce EIGRP bandwidth utilization over WAN links.
EIGRP stub feature has the following advantages:
- Limits query scope; requests hub router to not send queries as spokes rarely are intended for transit.
- Prevents spoke from being used for transit should an upstream failure occur.
- Conservation of local device resources such as memory, CPU.
Stub Options
When configuring an EIGRP stub, the following stub options are available:
- Connected: advertises directly connected networks.
- Summary: advertises summary routes.
- Receive-only: does not advertise any routes. Device only receives routes from neighbors.
- Static: advertises statically configured routes.
- Redistributed: advertises redistributed routes.
- Leak-map: advertises prefixes based on a leak-map.
By default, connected and summary routes are advertised when the command eigrp stub is configured.
In the configuration file i.e. running-configuration and startup-configuration, the EIGRP stub configuration with no
additional options is saved as eigrp stub connected summary .
Stub Configuration
The EIGRP stub router announces itself as a stub within the EIGRP hello packet. Neighboring routers detect the stub TLV field and update the EIGRP neighbor table to reflect the router's stub status. If a route goes active, EIGRP does not send EIGRP queries to an EIGRP stub router.
You configure a stub router by placing the command
eigrp stub {connected | receive-only | redistributed | static | summary}
under the EIGRP process for classic configuration and under the address family for named-mode configuration.
Named Mode
R9#confi t
Enter configuration commands, one per line. End with CNTL/Z.
R9(config)#router eigrp EIGRP_NAMED
R9(config-router)#add ipv4 uni a 1
R9(config-router-af)#eigrp stub ?
connected Do advertise connected routes
leak-map Allow dynamic prefixes based on the leak-map
receive-only Set receive only neighbor
redistributed Do advertise redistributed routes
static Do advertise static routes
summary Do advertise summary routes
R9(config-router-af)#eigrp stub
*Oct 9 21:07:22.463: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.69.1 (GigabitEthernet0/0) is down: peer info changed
R9(config-router-af)#do wr
Building configuration...
*Oct 9 21:07:24.127: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.69.1 (GigabitEthernet0/0) is up: new adjacency[OK]
R9(config-router-af)#
Classic Mode
R4(config-router)#router eigrp 1
R4(config-router)#eigrp stub connected redistributed
Verification of EIGRP stub configuration of a neighboring router.
R3#show ip eigrp ne de
EIGRP-IPv4 Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.200.34.2 Gi0/0 11 00:09:55 86 516 0 12
Version 10.0/2.0, Retrans: 0, Retries: 0, Prefixes: 9
Topology-ids from peer - 0
Stub Peer Advertising (CONNECTED REDISTRIBUTED ) Routes
Suppressing queries
1 10.200.13.1 Gi1/0 7 00:53:24 49 294 0 24
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 21
Topology-ids from peer - 0
R3#
Verification of Stub Configuration
Stub configuration can be confirmed on a local router using the command:
show ip protocols.
R10#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_BR2) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 10.255.254.10
Stub, connected, summary
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 9
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.255.3.1/32
10.255.254.8/30
Routing Information Sources:
Gateway Distance Last Update
10.255.254.9 90 00:05:43
10.255.3.2 90 00:05:41
Distance: internal 90 external 170
Verification of EIGRP stub configuration on an EIGRP neighbor device
R6(config-router-af)#
*Oct 9 21:23:05.431: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.0.69.2 (GigabitEthernet2/0) is up: new adjacency
R6(config-router-af)#do show ip eigrp ne deta
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Neighbors for AS(1)
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
0 10.0.69.2 Gi2/0 11 00:00:08 126 756 0 27
Version 10.0/2.0, Retrans: 0, Retries: 0, Prefixes: 6
Topology-ids from peer - 0
Stub Peer Advertising (CONNECTED SUMMARY ) Routes
Suppressing queries
6 10.100.1.19 Fa3/1 6 00:01:52 40 240 0 99
Version 10.0/2.0, Retrans: 2, Retries: 0, Prefixes: 17
Topology-ids from peer - 0
2 10.100.1.20 Fa3/1 11 00:01:52 54 324 0 32
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 2
Topology-ids from peer - 0
5 10.0.16.1 Fa3/0 11 00:09:37 71 426 0 6
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 2
Topology-ids from peer - 0
4 10.100.1.7 Gi0/0 6 00:18:03 72 432 0 101
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 6
Topology-ids from peer - 0
3 10.100.1.18 Fa3/1 6 00:18:07 60 360 0 100
Version 10.0/2.0, Retrans: 1, Retries: 0, Prefixes: 17
Topology-ids from peer - 0
1 10.100.1.8 Gi0/0 6 01:22:59 44 264 0 100
Version 10.0/2.0, Retrans: 2, Retries: 0, Prefixes: 8
Topology-ids from peer - 0
R6(config-router-af)#
The above output shows that the local device is suppressing queries to its stub neighbor.
The different EIGRP stub options can be combined to further refine the type of routes advertised by the stub device. The command:
R9(config)#router eigrp EIGRP_NAMED
R9(config-router)#add ipv4 uni a 1
R9(config-router-af)#eigrp stub connected summary static redistributed
The above configuration advertises connected, summary, statically configured and redistributed prefixes.
Stub-Site
The EIGRP stub site feature builds on EIGRP stub capabilities that allow a router to advertise itself as a stub to peers only on the specified WAN interfaces but allow it to exchange routes learned on LAN interfaces with other routers in the same branch/spoke network.
EIGRP stub sites provide the following key benefits:
- EIGRP neighbors on WAN links do not send EIGRP queries to the remote site when a route becomes active.
- The EIGRP stub site feature allows downstream routers to receive and advertise network prefixes across the WAN.
- The EIGRP stub site feature prevents the EIGRP stub site route from being a transit site.
Stub Site Config
The EIGRP stub-site feature is available in named EIGRP configuration mode only.
The stub-site feature is configured on devices/routers that are connected to WAN link on the branch.
The configuration of stub site ID is done in EIGRP address family mode using the command
eigrp stub-site.
The stub site ID is applied to all incoming routes on WAN interfaces.
The eigrp stub-site command is mutually exclusive with the
eigrp stub command. You cannot execute both commands on a
device.
This eigrp stub-site command resets the peers on WAN interfaces and initiates relearning of routes from WAN neighbors.
Interfaces connected towards hub or WAN are identified so that routes learnt through neighbors on such interfaces are part
of a list of a given route. This is achieved via the stub-site wan-interface
command configured in the address family
interface configuration mode. On the identified interfaces, neighbors treat WAN interfaces as stub.
The WAN interfaces are configured with the stub-site wan-interface command.
The stub site function and identifier are enabled with the command
eigrp stub-site <as-number:identifier>.
The as-number:identifier must remain the same for all devices in a site.
Remote prefixes that are learned through the WAN interface are tagged with the EIGRP stub site
attribute.
R9> enable
R9# configure terminal
R9(config)# router eigrp EIGRP_NAMED
R9(config-router)# address-family ipv4 autonomous-system 1
R9(config-router-af)# network 172.16.0.0
R9(config-router-af)# eigrp stub-site 101:100
R9(config-router-af)# af-interface gigabitethernet 0/0
R9(config-router-af-interface)# stub-site wan-interface
R9(config-router-af-interface)# end
Stub Router Flags
A major benefit to the EIGRP stub site feature is that the stub functionality can be passed to a branch site that has multiple edge routers. As long as each router is configured with the EIGRP stub site feature and maintains the same stub site identifier, the site does not become a transit routing site; however, it still allows for all the networks to be easily advertised to other routers in the EIGRP autonomous system.
Default Route Advertisement
Default route propagation in EIGRP can be configured using the summary route 0.0.0.0/0 or through redistribution of a default route.Summary Address 0.0.0.0/0
A default route can be propagated in EIGRP using the summary address 0.0.0.0 0.0.0.0. This default route summary suppresses every single IPv4 prefix that was advertised by the local device. To advertise other IPv4 prefixes, configuration of a leakmap may be required. Summary can be configured on the interface in classic EIGRP configuration and af-interface in named EIGRP.
R4(config)#interface g0/0
R4(config-if)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0
R4(config)#do show ip route
Codes: L - local, C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
D* 0.0.0.0/0 is a summary, 00:00:03, Null0
8.0.0.0/24 is subnetted, 1 subnets
S 8.8.8.0 [1/0] via 10.200.45.2
10.0.0.0/8 is variably subnetted, 38 subnets, 6 masks
D 10.0.12.0/30 [90/3328] via 10.200.34.1, 10:02:37, GigabitEthernet0/0
D 10.0.16.0/30 [90/28672] via 10.200.34.1, 10:02:37, GigabitEthernet0/0
D 10.0.26.0/30 [90/3584] via 10.200.34.1, 09:48:35, GigabitEthernet0/0
D 10.0.69.0/30 [90/3840] via 10.200.34.1, 09:48:32, GigabitEthernet0/0
D 10.1.10.0/24
[90/131072] via 10.200.34.1, 10:02:37, GigabitEthernet0/0
D 10.1.11.0/24
R4(config)#
On downstream routers, the default route can be verified using the command show ip route.
R8#show ip route | b Gate
Gateway of last resort is 10.100.1.6 to network 0.0.0.0
D* 0.0.0.0/0 [90/35840] via 10.100.1.6, 00:10:54, GigabitEthernet0/0
10.0.0.0/8 is variably subnetted, 36 subnets, 6 masks
D 10.0.12.0/30 [90/20480] via 10.100.1.6, 03:20:21, GigabitEthernet0/0
D 10.0.16.0/30 [90/153600] via 10.100.1.17, 03:20:22, FastEthernet4/1
[90/107520] via 10.100.1.6, 03:20:22, GigabitEthernet0/0
D 10.0.26.0/30 [90/15360] via 10.100.1.6, 03:20:21, GigabitEthernet0/0
D 10.0.69.0/30 [90/15360] via 10.100.1.6, 03:20:22, GigabitEthernet0/0
D 10.1.10.0/24 [90/2667520] via 10.100.1.20, 02:55:23, FastEthernet4/1
[90/2672640] via 10.100.1.17, 02:55:23, FastEthernet4/1
[90/2580480] via 10.100.1.6, 02:55:23, GigabitEthernet0/0
D 10.1.11.0/24 [90/2667520] via 10.100.1.20, 02:55:23, FastEthernet4/1
[90/2672640] via 10.100.1.17, 02:55:23, FastEthernet4/1
[90/2580480] via 10.100.1.6, 02:55:23, GigabitEthernet0/0
D 10.3.10.0/24 [90/2672640] via 10.100.1.20, 02:55:23, FastEthernet4/1
[90/2677760] via 10.100.1.17, 02:55:23, FastEthernet4/1
R8#show ip route 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "eigrp 1", distance 90, metric 35840, candidate default path, type internal
Redistributing via eigrp 1
Last update from 10.100.1.6 on GigabitEthernet0/0, 00:16:41 ago
Routing Descriptor Blocks:
* 10.100.1.6, from 10.100.1.6, 00:16:41 ago, via GigabitEthernet0/0
Route metric is 35840, traffic share count is 1
Total delay is 60 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 5
The default route is propagated as an internal EIGRP route.
Default Route Advertisement Through Redistribution
In this method of default route propagation, the default route of a router is redistributed into EIGRP. In many cases, this default route is a static route. This static route can then be redistributed into EIGRP. Because it is redistributed, the propagated default route will be advertised as an EIGRP external route.
R4(config)#ip route 0.0.0.0 0.0.0.0 10.200.45.2
R4(config)#router eigrp 1
R4(config-router)#redistribute static metric 1000000 1 255 1 1500
R4(config-router)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
Redistributing: static, ospf 100
EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 10.200.45.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
On a downstream router, the default route can be confirmed by the command show ip route.
R8#show ip route | b Ga
Gateway of last resort is 10.100.1.20 to network 0.0.0.0
D*EX 0.0.0.0/0 [170/3485013] via 10.100.1.20, 00:11:28, FastEthernet4/1
[170/3490133] via 10.100.1.17, 00:11:28, FastEthernet4/1
[170/3444053] via 10.100.1.6, 00:11:28, GigabitEthernet0/0
EIGRP Traffic Engineering
EIGRP traffic engineering involves modifying some default features of EIGRP in order to optimize routing according to the network design. Traffic engineering may include configurations such as:
- Metric modification using offset lists
- Modification of variables that affect metric calculation such as bandwidth, delay etc
- Changing K-values
- Modification of load balancing
- Route summarization
- Modification of Administrative Distance
Custom K-values
If the design of the network requires that delay and load be included in metric
calculation in addition to bandwidth and delay, modification of the K-values may be
required. K-values for the path metric calculation are set with the command
metric weights <tos> <K1> <K2> <K3> <K4> <K5> [<K6>] under the EIGRP process.
The TOS value always has a value of 0, and the K6 value is used for wide metric
calculation.
K-values are in the range 0 - 255. To ensure consistent metric calculation in an EIGRP autonomous system, the K-values
must match between EIGRP neighbors.
The K-values are included in an EIGRP hello packet.
The K-values are displayed with the show ip protocols command.
It is important to note that changing the value of K6 from default of zero(0) results in a K-value mismatch for a peer relationship between a classically-configured and named-EIGRP configured device. This will result in the peer relationship dropping.
*Apr 7 10:23:51.411: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.13.1 (GigabitEthernet1/0) is down: K-value mismatch
Modifying Metric Values
Default EIGRP composite metric is based on bandwidth and delay. Bandwidth is the lowest bandwidth along the path on a per prefix basis. Delay is cumulative on a hop-by-hop basis. It is recommended to influence path selection by modifying the interface delay. The interface delay is largely used by EIGRP for metric calculation unlike other variables such as bandwidth that may be used by other processes running on the router such as OSPF in their route metric calculation.
Modifying the delay only affects EIGRP. The delay can be configured with the interface command:
delay <1 - 16777215>. The delay value parameter is in
tens of microseconds.
In the output below, EIGRP selects the route path via interface GigabitEthernet1/0 to the network 10.8.10.0/24. The path via this interface has a cumulative delay of 32 microseconds.
R3#show ip route 10.8.10.0
Routing entry for 10.8.10.0/24
Known via "eigrp 1", distance 90, metric 3328, type internal
Redistributing via eigrp 1
Last update from 10.200.13.1 on GigabitEthernet1/0, 01:18:38 ago
Routing Descriptor Blocks:
* 10.200.13.1, from 10.200.13.1, 01:18:38 ago, via GigabitEthernet1/0
Route metric is 3328, traffic share count is 1
Total delay is 32 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
R3#show ip eigrp topology 10.8.10.0/24
EIGRP-IPv4 Topology Entry for AS(1)/ID(3.3.3.3) for 10.8.10.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3328
Descriptor Blocks:
10.200.13.1 (GigabitEthernet1/0), from 10.200.13.1, Send flag is 0x0
Composite metric is (3328/3072), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 31 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 8.8.8.8
10.200.23.1 (FastEthernet3/0), from 10.200.23.1, Send flag is 0x0
Composite metric is (28416/2816), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 111 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 8.8.8.8
The interface GigabitEthernet1/0 has a default delay of 10 microseconds. The delay is increased from 10 microseconds to 10000 microseconds. Note that the delay value entered is in tens of microseconds. This increases the metric of the path through interface GigabitEthernet1/0 and EIGRP then selects the path through interface FastEthernet3/0 as its metric is now considered the best.
R3#show interface g1/0
GigabitEthernet1/0 is up, line protocol is up
Hardware is 82543, address is ca03.042e.001c (bia ca03.042e.001c)
Internet address is 10.200.13.2/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, link type is auto, media type is SX
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:04, output 00:00:02, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1381 packets input, 118797 bytes, 0 no buffer
Received 967 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
1718 packets output, 148281 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
R3(config-if)#delay ?
<1-16777215> Throughput delay (tens of microseconds)
R3(config-if)#delay 1000
R3(config-if)#do show interface g1/0
GigabitEthernet1/0 is up, line protocol is up
Hardware is 82543, address is ca03.042e.001c (bia ca03.042e.001c)
Internet address is 10.200.13.2/30
MTU 1500 bytes, BW 1000000 Kbit/sec, DLY 10000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full Duplex, 1Gbps, link type is auto, media type is SX
output flow-control is unsupported, input flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
1479 packets input, 127044 bytes, 0 no buffer
R3(config-if)#do show ip route 10.8.10.0
Routing entry for 10.8.10.0/24
Known via "eigrp 1", distance 90, metric 28416, type internal
Redistributing via eigrp 1
Last update from 10.200.23.1 on FastEthernet3/0, 00:00:08 ago
Routing Descriptor Blocks:
* 10.200.23.1, from 10.200.23.1, 00:00:08 ago, via FastEthernet3/0
Route metric is 28416, traffic share count is 1
Total delay is 112 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 2
R3(config-if)#do show ip eigrp topology 10.8.10.0/24
EIGRP-IPv4 Topology Entry for AS(1)/ID(3.3.3.3) for 10.8.10.0/24
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3328
Descriptor Blocks:
10.200.23.1 (FastEthernet3/0), from 10.200.23.1, Send flag is 0x0
Composite metric is (28416/2816), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 111 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 2
Originating router is 8.8.8.8
10.200.13.1 (GigabitEthernet1/0), from 10.200.13.1, Send flag is 0x0
Composite metric is (259072/3072), route is Internal
Vector metric:
Minimum bandwidth is 1000000 Kbit
Total delay is 10021 microseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 8.8.8.8
R3(config-if)#
EIGRP Load Balancing: Equal Cost and Unequal Cost
All routing protocols load-balance over multiple paths when the metric is the same across each path. Installing multiple paths into the RIB with the same metric for the same prefix is called equal-cost multipathing (ECMP) routing.
Unequal Cost Load Balancing: variance
EIGRP is the only IGP today that supports unequal cost load-balancing.
The variance <multiplier> command of EIGRP controls it's ability to support
equal-cost or unequal cost load balancing. A variance multiplier value of one(1) causes EIGRP to perform equal-cost
load-balancing. By default, the variance multiplier is one (1).
R8show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_8) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 8.8.8.8
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 22
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.0.3/32
10.100.1.0/30
10.100.68.2/32
Passive Interface(s):
FastEthernet4/0
Routing Information Sources:
Gateway Distance Last Update
10.100.68.1 90 00:04:01
10.100.1.4 90 00:04:01
10.100.0.2 90 00:04:01
10.100.1.2 90 00:04:01
10.100.1.1 90 00:04:01
10.100.0.1 90 00:04:01
Distance: internal 90 external 170
R8#
R8#show ip route eigrp
Codes: L - local, C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 26 subnets, 5 masks
D 10.0.12.0/30 [90/20480] via 10.100.0.1, 03:53:31, GigabitEthernet0/0
D 10.0.16.0/30 [90/107520] via 10.100.0.1, 03:53:31, GigabitEthernet0/0
D 10.0.26.0/30 [90/15360] via 10.100.0.1, 03:53:31, GigabitEthernet0/0
D 10.3.10.0/24
[90/2585600] via 10.100.0.1, 03:49:39, GigabitEthernet0/0
D 10.3.11.0/24
[90/2585600] via 10.100.0.1, 03:49:39, GigabitEthernet0/0
D 10.3.12.0/25
[90/2585600] via 10.100.0.1, 03:49:39, GigabitEthernet0/0
D 10.3.12.128/25
[90/2585600] via 10.100.0.1, 03:49:39, GigabitEthernet0/0
D 10.7.10.0/24 [90/10880] via 10.100.0.2, 03:53:31, GigabitEthernet0/0
D 10.7.11.0/24 [90/10880] via 10.100.0.2, 03:53:31, GigabitEthernet0/0
D 10.7.12.0/24 [90/10880] via 10.100.0.2, 03:53:31, GigabitEthernet0/0
D 10.200.13.0/30
[90/25600] via 10.100.0.1, 03:49:43, GigabitEthernet0/0
D 10.200.23.0/30
[90/112640] via 10.100.0.1, 03:53:31, GigabitEthernet0/0
D 10.200.34.0/30
[90/30720] via 10.100.0.1, 03:49:39, GigabitEthernet0/0
D 10.200.45.0/30
[90/109832] via 10.100.0.1, 03:46:01, GigabitEthernet0/0
D EX 192.168.100.0/24
[170/114952] via 10.100.0.1, 03:45:57, GigabitEthernet0/0
D EX 192.168.101.0/24
[170/114952] via 10.100.0.1, 03:45:57, GigabitEthernet0/0
R8#
To support unequal cost load-balancing, a variance multiplier greater than one must be configured. If set to two (2), EIGRP multiplies the feasible distance by the variance multiplier. All paths whose metric is less than the product of this multiplication are added to the routing table. However, these paths are still subjected to the feasibility condition to ensure that they are loop-free before they are added to the routing table.
EIGRP allows load distribution over unequal paths. Only FS are candidates for load-balancing. Unequal cost load-balancing is
controlled by variance command. For a path to be considered for unequal cost load balancing, its feasible distance must be
less than the product of the feasible distance of the successor and variance multiplier.
Traffic share is automatically calculated over the links based on a ratio proportional to their composite metrics.
Actual load-balancing still controlled by switching paths e.g. CEF per flow.
Dividing the feasible successor metric by the successor route metric provides the variance multiplier. The variance multiplier is a whole number, and any remainders should always round up.
In classic-mode EIGRP, unequal cost load balancing is configured using the
variance command under the EIGRP router
process.
R3(config)#router eigrp 1
R3(config-router)#variance 2
R3(config-router)#do show ip route eigrp | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 27 subnets, 5 masks
D 10.0.12.0/30 [90/3072] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.0.16.0/30 [90/28416] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.0.26.0/30 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.7.10.0/24 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.7.11.0/24 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.7.12.0/24 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.8.10.0/24 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.8.11.0/24 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.8.12.0/24 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.100.0.0/29 [90/28672] via 10.200.23.1, 00:00:03, FastEthernet3/0
[90/28672] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.100.1.0/29 [90/3328] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.100.68.0/24 [90/30976] via 10.200.23.1, 00:00:03, FastEthernet3/0
[90/28928] via 10.200.13.1, 00:00:03, GigabitEthernet1/0
D 10.200.45.0/30
[90/19200] via 10.200.34.2, 00:00:03, GigabitEthernet0/0
D EX 192.168.100.0/24
[170/19456] via 10.200.34.2, 00:00:03, GigabitEthernet0/0
D EX 192.168.101.0/24
[170/19456] via 10.200.34.2, 00:00:03, GigabitEthernet0/0
R3(config-router)#
R3(config-router)#
R3(config-router)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 3.3.3.3
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 2
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.3.0.0/16
10.200.13.0/30
10.200.23.2/32
10.200.34.0/30
Routing Information Sources:
Gateway Distance Last Update
10.200.13.1 90 00:00:25
10.200.23.1 90 00:00:25
10.200.34.2 90 00:00:25
Distance: internal 90 external 170
R3(config-router)#
In named-mode, the variance command can be configured under
the topology base section of the appropriate address family.
R8#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
R8(config)#router eigrp EIGRP_8
R8(config-router)#address-family ipv4 unicast autonomous-system 1
R8(config-router-af)#topology base
R8(config-router-af-topology)#variance 3
R8(config-router-af-topology)#do show ip route eigrp
Codes: L - local, C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 26 subnets, 5 masks
D 10.0.12.0/30 [90/20480] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.0.16.0/30 [90/153600] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/107520] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.0.26.0/30 [90/15360] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.3.10.0/24 [90/2672640] via 10.100.1.4, 00:00:02, FastEthernet4/1
[90/2677760] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.3.11.0/24 [90/2672640] via 10.100.1.4, 00:00:02, FastEthernet4/1
[90/2677760] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.3.12.0/25 [90/2672640] via 10.100.1.4, 00:00:02, FastEthernet4/1
[90/2677760] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.3.12.128/25 [90/2672640] via 10.100.1.4, 00:00:02, FastEthernet4/1
[90/2677760] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.7.10.0/24 [90/10880] via 10.100.0.2, 00:00:02, GigabitEthernet0/0
D 10.7.11.0/24 [90/10880] via 10.100.0.2, 00:00:02, GigabitEthernet0/0
D 10.7.12.0/24 [90/10880] via 10.100.0.2, 00:00:02, GigabitEthernet0/0
D 10.200.13.0/30
[90/25600] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.200.23.0/30 [90/153600] via 10.100.1.4, 00:00:02, FastEthernet4/1
[90/158720] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/112640] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.200.34.0/30
[90/30720] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D 10.200.45.0/30 [90/168960] via 10.100.1.4, 00:00:02, FastEthernet4/1
[90/174080] via 10.100.1.1, 00:00:02, FastEthernet4/1
[90/109832] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D EX 192.168.100.0/24 [170/174080] via 10.100.1.4, 00:00:02, FastEthernet4/1
[170/179200] via 10.100.1.1, 00:00:02, FastEthernet4/1
[170/114952] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
D EX 192.168.101.0/24 [170/174080] via 10.100.1.4, 00:00:02, FastEthernet4/1
[170/179200] via 10.100.1.1, 00:00:02, FastEthernet4/1
[170/114952] via 10.100.0.1, 00:00:02, GigabitEthernet0/0
R8(config-router-af-topology)#do show ip route 10.3.10.0
Routing entry for 10.3.10.0/24
Known via "eigrp 1", distance 90, metric 2585600, type internal
Redistributing via eigrp 1
Last update from 10.100.1.1 on FastEthernet4/1, 00:00:27 ago
Routing Descriptor Blocks:
10.100.1.4, from 10.100.1.4, 00:00:27 ago, via FastEthernet4/1
Route metric is 2672640, traffic share count is 29
Total delay is 5120 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
10.100.1.1, from 10.100.1.1, 00:00:27 ago, via FastEthernet4/1
Route metric is 2677760, traffic share count is 29
Total delay is 5130 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
* 10.100.0.1, from 10.100.0.1, 00:00:27 ago, via GigabitEthernet0/0
Route metric is 2585600, traffic share count is 30
Total delay is 5040 microseconds, minimum bandwidth is 1000000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 4
R8(config-router-af-topology)#
Confirmation of load-balancing at Layer 2 level can be confirmed with the command
show ip cef <network-address>
R7#show ip cef 10.3.10.0 detail
10.3.10.0/24, epoch 0, per-destination sharing
nexthop 10.100.1.17 FastEthernet4/0
nexthop 10.100.1.20 FastEthernet4/0
nexthop 10.100.1.6 GigabitEthernet0/0
R8#
Maximum Paths
The number of paths to a destination network that can be installed in the
routing table can be controlled by the maximum-paths <1-16> command.
On Cisco devices, the default number of maximum paths is four (4).
Maximum paths applies to equal cost and unequal cost load-balancing.
In named-mode, maximum paths is configured under the topology base section of the appropriate address family. In the following configuration, the default maximum paths is decreased to two (2).
R8(config)#router eigrp EIGRP_8
R8(config-router)#address-family ipv4 unicast autonomous-system 1
R8(config-router-af)#topology base
R8(config-router-af-topology)#maximum-paths ?
<1-32> Number of paths
R8(config-router-af-topology)#maximum-paths 2
R8(config-router-af-topology)#do show ip route eigrp
Codes: L - local, C - connected, S - static, 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
i - IS-IS, su - IS-IS summary, 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, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 26 subnets, 5 masks
D 10.0.12.0/30 [90/20480] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.0.16.0/30 [90/153600] via 10.100.1.1, 00:00:05, FastEthernet4/1
[90/107520] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.0.26.0/30 [90/15360] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.3.10.0/24 [90/2672640] via 10.100.1.4, 00:00:05, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.3.11.0/24 [90/2672640] via 10.100.1.4, 00:00:05, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.3.12.0/25 [90/2672640] via 10.100.1.4, 00:00:05, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.3.12.128/25 [90/2672640] via 10.100.1.4, 00:00:05, FastEthernet4/1
[90/2585600] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.7.10.0/24 [90/10880] via 10.100.0.2, 00:00:05, GigabitEthernet0/0
D 10.7.11.0/24 [90/10880] via 10.100.0.2, 00:00:05, GigabitEthernet0/0
D 10.7.12.0/24 [90/10880] via 10.100.0.2, 00:00:05, GigabitEthernet0/0
D 10.200.13.0/30
[90/25600] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.200.23.0/30 [90/153600] via 10.100.1.4, 00:00:05, FastEthernet4/1
[90/112640] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.200.34.0/30
[90/30720] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D 10.200.45.0/30 [90/168960] via 10.100.1.4, 00:00:05, FastEthernet4/1
[90/109832] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D EX 192.168.100.0/24 [170/174080] via 10.100.1.4, 00:00:05, FastEthernet4/1
[170/114952] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
D EX 192.168.101.0/24 [170/174080] via 10.100.1.4, 00:00:05, FastEthernet4/1
[170/114952] via 10.100.0.1, 00:00:05, GigabitEthernet0/0
R8(config-router-af-topology)#do show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_8) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 8.8.8.8
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 2
Maximum hopcount 100
Maximum metric variance 3
Total Prefix Count: 22
Total Redist Count: 0
...
Distance: internal 90 external 170
In EIGRP classic-mode, the maximum-paths command is configured under the EIGRP routing process.
Forwarding Behaviour
By default, path selection or forwarding is based on metric ratio. Ratio uses integers and results are rounded down. Cisco's use of CEF can alter load-balancing behaviour. By default, CEF forwards traffic based on per-destination load-balancing where all traffic to a single destination is sent via a single path. If forwarding behaviour is not expected, look at the CEF mode.
R8#show ip cef
Prefix Next Hop Interface
0.0.0.0/0 no route
0.0.0.0/8 drop
0.0.0.0/32 receive
10.0.12.0/30 10.100.0.1 GigabitEthernet0/0
10.0.16.0/30 10.100.1.1 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
10.0.26.0/30 10.100.0.1 GigabitEthernet0/0
10.3.10.0/24 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
10.3.11.0/24 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
10.3.12.0/25 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
10.3.12.128/25 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
10.7.10.0/24 10.100.0.2 GigabitEthernet0/0
10.7.11.0/24 10.100.0.2 GigabitEthernet0/0
10.7.12.0/24 10.100.0.2 GigabitEthernet0/0
10.8.10.0/24 attached Loopback10
10.8.10.0/32 receive Loopback10
10.8.10.1/32 receive Loopback10
Prefix Next Hop Interface
10.8.10.255/32 receive Loopback10
10.8.11.0/24 attached Loopback11
10.8.11.0/32 receive Loopback11
10.8.11.1/32 receive Loopback11
10.8.11.255/32 receive Loopback11
10.8.12.0/24 attached Loopback12
10.8.12.0/32 receive Loopback12
10.8.12.1/32 receive Loopback12
10.8.12.255/32 receive Loopback12
10.100.0.0/29 attached GigabitEthernet0/0
10.100.0.0/32 receive GigabitEthernet0/0
10.100.0.1/32 attached GigabitEthernet0/0
10.100.0.2/32 attached GigabitEthernet0/0
10.100.0.3/32 receive GigabitEthernet0/0
10.100.0.7/32 receive GigabitEthernet0/0
10.100.1.0/29 attached FastEthernet4/1
10.100.1.0/32 receive FastEthernet4/1
10.100.1.1/32 attached FastEthernet4/1
10.100.1.2/32 attached FastEthernet4/1
10.100.1.3/32 receive FastEthernet4/1
10.100.1.4/32 attached FastEthernet4/1
10.100.1.7/32 receive FastEthernet4/1
Prefix Next Hop Interface
10.100.68.0/24 attached FastEthernet4/0
10.100.68.0/32 receive FastEthernet4/0
10.100.68.2/32 receive FastEthernet4/0
10.100.68.255/32 receive FastEthernet4/0
10.200.13.0/30 10.100.0.1 GigabitEthernet0/0
10.200.23.0/30 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
10.200.34.0/30 10.100.0.1 GigabitEthernet0/0
10.200.45.0/30 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
127.0.0.0/8 drop
192.168.100.0/24 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
192.168.101.0/24 10.100.1.4 FastEthernet4/1
10.100.0.1 GigabitEthernet0/0
224.0.0.0/4 drop
224.0.0.0/24 receive
240.0.0.0/4 drop
255.255.255.255/32 receive
R8#
R8#show ip cef 192.168.101.0/24
192.168.101.0/24
nexthop 10.100.1.4 FastEthernet4/1
nexthop 10.100.0.1 GigabitEthernet0/0
R8#show ip route 192.168.101.0
Routing entry for 192.168.101.0/24
Known via "eigrp 1", distance 170, metric 114952, type external
Redistributing via eigrp 1
Last update from 10.100.0.1 on GigabitEthernet0/0, 00:46:09 ago
Routing Descriptor Blocks:
* 10.100.1.4, from 10.100.1.4, 00:46:09 ago, via FastEthernet4/1
Route metric is 174080, traffic share count is 79
Total delay is 240 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 5
10.100.0.1, from 10.100.0.1, 00:46:09 ago, via GigabitEthernet0/0
Route metric is 114952, traffic share count is 120
Total delay is 160 microseconds, minimum bandwidth is 155000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 6
R8#
EIGRP Traffic Sharing
EIGRP load balancing provides the option to control the traffic sharing behaviour when multiple paths to the
same destination network are installed in the routing table. The command to control the traffic distribution across
various paths is traffic-share [balanced | min].
To control how traffic is distributed among routes when there are multiple routes to the same destination network that
have different metrics, the recommended configuration is traffic-share balanced command.
With the balanced keyword, the router distributes traffic proportionately to the ratios of the metrics that are
associated with different routes. This is the default setting.
Similarly, if the traffic-share command with the
min keyword is configured, the traffic is sent only across the
minimum-cost path, even when there are multiple paths in the routing table. This is identical to the
forwarding behavior without use of the variance command. The min keyword has the additional option
across-interfaces.
However, if you use the traffic-share min command and the
variance command, even though traffic is sent over the
minimum-cost path only, all feasible routes get installed into the routing table, which decreases
convergence times.
Route Filtering Using ACLs, Prefix-lists and Route-Maps
EIGRP supports filtering of routes as they are received or advertised out an interface. Filtering of routes can be accomplished using:
- Access control lists (ACLs)
- IP prefix lists
- Route maps
- Gateway IP addresses
Route filtering involves selectively identifying routes that are to be advertised or received from neighbor routers. The benefits of route filtering include:
- to reduce memory utilization of devices
- to improve security.
Filtering can be implemented on inbound routes or outbound routes. Inbound filtering drops routes before they are processed by the DUAL algorithm resulting in the routes not being installed into the RIB because they are not known. Outbound filtering occurs after route processing by DUAL and the routes are installed into the local RIB of the advertising router. Outbound filtering affects the advertisement of prefixes to neighbors.
Filtering is accomplished with the command:
distribute-list {acl-number | acl-name | prefix prefix-list-name | route-map route-map-name |
gateway prefix-list-name} {in | out} [interface-id]
EIGRP classic configuration places the command under the EIGRP process, while
named-mode configuration places the command
under topology base configuration mode.
Prefixes that match against deny statements are filtered, and prefixes that match
against a permit statement are passed.
If the distribute-list filtering is applied without referencing an interface, then it gets applied to all interfaces.
EIGRP Route Filtering using Access Control Lists
Distribute-list implements filtering by referencing an Access Control List (ACL). The ACL is configured with permit and deny statements. Routes that are permitted pass through the filter and routes that are denied are filtered out.
The following output shows the routing table before the route filtering is applied. The network to be filtered by the distribute-list is the address 192.168.16.0/23 (wildcard mask of 0.0.1.255). This, in essence, denies the redistributed routes 192.168.16.0 and 192.168.17.0.
R2(config-router-af-topology)#do show ip route eigrp | b Ga
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 21 subnets, 4 masks
D 10.0.16.0/30
[90/107520] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.0.69.0/30 [90/15360] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.1.10.0/24
[90/2667520] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.1.11.0/24
[90/2667520] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.9.10.0/24 [90/16000] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.9.11.0/24 [90/16000] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.9.13.0/24 [90/16000] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.9.14.0/24 [90/16000] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.9.15.0/24 [90/16000] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.9.16.0/24 [90/16000] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.100.1.0/28
[90/15360] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.200.13.0/30
[90/112640] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.200.23.0/30
[90/163840] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.200.34.0/30
[90/117760] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D 10.200.45.0/30
[90/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.10.0/32 is subnetted, 1 subnets
D EX 192.168.10.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.11.0/32 is subnetted, 1 subnets
D EX 192.168.11.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.12.0/32 is subnetted, 1 subnets
D EX 192.168.12.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.13.0/32 is subnetted, 1 subnets
D EX 192.168.13.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.14.0/32 is subnetted, 1 subnets
D EX 192.168.14.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.15.0/32 is subnetted, 1 subnets
D EX 192.168.15.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.16.0/32 is subnetted, 1 subnets
D EX 192.168.16.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
192.168.17.0/32 is subnetted, 1 subnets
D EX 192.168.17.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
D EX 192.168.18.1
[170/168960] via 10.100.1.17, 00:01:09, GigabitEthernet2/0
Access Control Lists (ACLs) can be used to identify the prefixes to be filtered (inbound or outbound). The following sequence of configurations guide on how to filter prefixes using an ACL:
- Identify the Prefixes to be Filtered Using an Access Control List (ACL):
R2(config)#ip access-list standard ACL_19216816_2
R2(config-std-nacl)#10 deny 192.168.16.0 0.0.1.255
R2(config-std-nacl)#20 permit any
R2(config-std-nacl)#exit
R2(config)#
-
Apply the filter using the
distribute-listcommand and reference the ACL created in Step 1:Named mode
R2(config)#router eigrp EIGRP_NAMED
R2(config-router)#address-family ipv4 unicast autonomous-system 1
R2(config-router-af)#topology base
R2(config-router-af-topology)#distribute-list ACL_19216816_2 in
*Oct 10 17:18:55.799: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.17 (GigabitEthernet2/0) is resync: route configuration changedR2(config-router-af-topology)#
Classic Mode
R2(config)#router eigrp 1
R2(config-router)#distribute-list ACL_19216816_2 in
*Oct 10 17:18:55.799: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.17 (GigabitEthernet2/0) is resync: route configuration changedR2(config-router-af-topology)#
R2(config)#do show ip route eigrp | b Ga
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 21 subnets, 4 masks
D 10.0.16.0/30
[90/107520] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.0.69.0/30 [90/15360] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.1.10.0/24
[90/2667520] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.1.11.0/24
[90/2667520] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.9.10.0/24 [90/16000] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.9.11.0/24 [90/16000] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.9.13.0/24 [90/16000] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.9.14.0/24 [90/16000] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.9.15.0/24 [90/16000] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.9.16.0/24 [90/16000] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.100.1.0/28
[90/15360] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.200.13.0/30
[90/112640] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.200.23.0/30
[90/163840] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.200.34.0/30
[90/117760] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
D 10.200.45.0/30
[90/168960] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
192.168.11.0/32 is subnetted, 1 subnets
D EX 192.168.11.1
[170/168960] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
192.168.13.0/32 is subnetted, 1 subnets
D EX 192.168.13.1
[170/168960] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
192.168.15.0/32 is subnetted, 1 subnets
D EX 192.168.15.1
[170/168960] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
192.168.17.0/32 is subnetted, 1 subnets
D EX 192.168.18.1
[170/168960] via 10.100.1.17, 00:01:16, GigabitEthernet2/0
R2(config)#
Filtering using Prefix Lists
Route filtering can be implemented using Prefix Lists.
- Define the prefix list
R9(config)#ip prefix-list PL_DENY_1921681617 seq 10 deny 192.168.16.0/23 le 32
R9(config)#ip prefix-list PL_DENY_1921681617 seq 20 permit 0.0.0.0/0 le 32
- Apply the prefix-list filter using the
distribute-listcommand;Named mode
R9(config)#router eigrp EIGRP_NAMED
R9(config-router)#address-family ipv4 unicast autonomous-system 1
R9(config-router-af)#topology base
R9(config-router-af-topology)#distribute-list prefix PL_DENY_1921681617 in Gigabitethernet0/0
Classic mode
R9(config)#router eigrp 1
R9(config-router)#distribute-list prefix PL_DENY_1921681617 in Gigabitethernet0/0
Verification
The distribute-list filtering has been applied to a specific interface as can be confirmed in the output of the
show ip protocols command.
R9#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
GigabitEthernet0/0 filtered by (prefix-list) PL_DENY_1921681617 (per-user), default is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 1.1.1.1
Stub, connected, summary
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 32
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.0.69.2/32
10.9.0.0/16
Routing Information Sources:
Gateway Distance Last Update
10.0.69.1 90 00:41:11
Distance: internal 90 external 170
The routing table confirms that the filtered prefixes are missing from the routing table.
R9#show ip route eigrp | b Gate
Gateway of last resort is not set
10.0.0.0/8 is variably subnetted, 32 subnets, 6 masks
D 10.0.12.0/30 [90/112640] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.0.16.0/30 [90/107520] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.1.10.0/24 [90/2667520] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.1.11.0/24 [90/2667520] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.7.0.0/20 [90/16000] via 10.0.69.1, 00:52:05, GigabitEthernet0/0
D 10.7.16.0/22 [90/16000] via 10.0.69.1, 00:52:05, GigabitEthernet0/0
D 10.7.25.0/24 [90/16000] via 10.0.69.1, 00:52:05, GigabitEthernet0/0
D 10.8.10.0/24 [90/16000] via 10.0.69.1, 01:29:04, GigabitEthernet0/0
D 10.8.11.0/24 [90/16000] via 10.0.69.1, 01:29:04, GigabitEthernet0/0
D 10.8.12.0/24 [90/16000] via 10.0.69.1, 01:29:04, GigabitEthernet0/0
D 10.8.13.0/24 [90/16000] via 10.0.69.1, 01:29:04, GigabitEthernet0/0
D 10.8.14.0/24 [90/16000] via 10.0.69.1, 01:29:04, GigabitEthernet0/0
D 10.100.1.0/28 [90/15360] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.100.1.16/28
[90/107520] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.200.13.0/30
[90/112640] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.200.23.0/30
[90/163840] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.200.34.0/30
[90/117760] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
D 10.200.45.0/30
[90/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.10.0/32 is subnetted, 1 subnets
D EX 192.168.10.1 [170/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.11.0/32 is subnetted, 1 subnets
D EX 192.168.11.1 [170/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.12.0/32 is subnetted, 1 subnets
D EX 192.168.12.1 [170/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.13.0/32 is subnetted, 1 subnets
D EX 192.168.13.1 [170/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.14.0/32 is subnetted, 1 subnets
D EX 192.168.14.1 [170/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.15.0/32 is subnetted, 1 subnets
D EX 192.168.15.1 [170/168960] via 10.0.69.1, 03:24:22, GigabitEthernet0/0
192.168.18.0/32 is subnetted, 1 subnets
D EX 192.168.18.1 [170/168960] via 10.0.69.1, 01:30:30, GigabitEthernet0/0
The configured prefix-list can be verified as shown in the following output;
R9#show ip prefix-list
ip prefix-list PL_DENY_1921681617: 2 entries
seq 10 deny 192.168.16.0/23 le 32
seq 20 permit 0.0.0.0/0 le 32
R9#
Filtering using a Route-Map
Route-maps reference Access Control Lists or prefix lists to identify traffic of interest. To configure route filtering using route maps, follow these steps:
- Identify the traffic of interest using an ACL or prefix list:
In this demonstration, we use a prefix list to identify redistributed EIGRP routes 192.168.0.0/16.
Note that the prefix-list
uses the permit statement to identify the network to be filtered if the route map
control statement is deny.
R8(config)#ip prefix-list PL_DENY_19216800 seq 10 permit 192.168.0.0/16 le 32 - Create a route map and reference the prefix list:
The route-map uses the deny statement to filter the network address that has been identified by the prefix-list.
The permit statement (second route-map statement) permits other routes that have not been denied.
R8(config)#route-map RM_DENY_19216800 deny 10
R8(config-route-map)#match ip address prefix-list PL_DENY_19216800
R8(config)#route-map RM_DENY_19216800 permit 20
R8(config)#do show route-map
route-map RM_DENY_19216800, deny, sequence 10
Match clauses:
ip address prefix-lists: PL_DENY_19216800
Set clauses:
Policy routing matches: 0 packets, 0 bytes
route-map RM_DENY_19216800, permit, sequence 20
Match clauses:
Set clauses:
Policy routing matches: 0 packets, 0 bytes
R8(config)#
- Apply the filter to EIGRP using the
distribute-listcommand:R8(config)#router eigrp EIGRP_NAMED
R8(config-router)#address-family ipv4 unicast autonomous-system 1
R8(config-router-af)#topology base
R8(config-router-af-topology)#distribute-list route-map RM_DENY_19216800 in
*Oct 10 22:33:24.295: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.7 (GigabitEthernet0/0) is resync: route configuration changed *Oct 10 22:33:24.295: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.18 (FastEthernet4/1) is resync: route configuration changed
*Oct 10 22:33:24.299: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.6 (GigabitEthernet0/0) is resync: route configuration changed *Oct 10 22:33:24.299: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.17 (FastEthernet4/1) is resync: route configuration changed
*Oct 10 22:33:24.303: %DUAL-5-NBRCHANGE: EIGRP-IPv4 1: Neighbor 10.100.1.20 (FastEthernet4/1) is resync: route configuration changed
R8(config-router-af-topology)#
Verification
R8(config-router-af-topology)#do show ip proto
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is (route-map) RM_DENY_1921680
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 10.8.14.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 26
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.1.16/28
10.100.0.0/23
Routing Information Sources:
Gateway Distance Last Update
10.100.1.7 90 00:00:09
10.100.1.6 90 00:00:09
10.100.1.20 90 00:00:09
10.100.1.18 90 00:00:09
10.100.1.17 90 00:00:09
Distance: internal 90 external 170
Traffic Steering with EIGRP Offset Lists
Offset lists allow for the modification of route metrics based on the direction of the update, a specific prefix,
or a combination of direction and prefix.
An offset list is configured with the command
offset-list <offset-value> [acl-number | acl-name] [in | out] [interface-id].
Specifying an interface restricts the conditional match for the offset list to the interface
that the route is received or advertised out of. If the interface argument is
not specified, the offset-list is applied to all interfaces.
EIGRP classic configuration places the command under the EIGRP process, while named-mode configuration
places the command under the topology base.
EIGRP Offset Configuration
To demonstrate how an offset list is used for traffic engineering, the path to the network 10.200.34.0/30 is modified. The EIGRP calculated route is:
R8#traceroute 10.200.34.1
Type escape sequence to abort.
Tracing the route to 10.200.34.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.100.1.6 12 msec 20 msec 20 msec
2 10.0.16.1 32 msec 28 msec 28 msec
3 10.200.13.2 56 msec * 36 msec
R8#show ip route 10.200.34.0
Routing entry for 10.200.34.0/30
Known via "eigrp 1", distance 90, metric 117760, type internal
Redistributing via eigrp 1
Last update from 10.100.1.6 on GigabitEthernet0/0, 02:59:57 ago
Routing Descriptor Blocks:
* 10.100.1.6, from 10.100.1.6, 02:59:57 ago, via GigabitEthernet0/0
Route metric is 117760, traffic share count is 1
Total delay is 130 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
R8#
R8#show ip eigrp topology 10.200.34.0/30
EIGRP-IPv4 VR(EIGRP_NAMED) Topology Entry for AS(1)/ID(10.8.14.1) for 10.200.34.0/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 15073280, RIB is 117760
Descriptor Blocks:
10.100.1.6 (GigabitEthernet0/0), from 10.100.1.6, Send flag is 0x0
Composite metric is (15073280/14417920), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 130000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 10.200.34.1
10.100.1.18 (FastEthernet4/1), from 10.100.1.18, Send flag is 0x0
Composite metric is (21626880/15073280), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 230000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4
Originating router is 10.200.34.1
10.100.1.17 (FastEthernet4/1), from 10.100.1.17, Send flag is 0x0
Composite metric is (20971520/14417920), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 220000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 10.200.34.1
R8#
The offset-list is configured by the following sequence of commands:
Step 1: Configure an access control list to identify the traffic;
R8(config)#ip access-list standard ACL_10200340
R8(config-std-nacl)#10 permit 10.200.34.0 0.0.0.3
Step 2: Modify the metrics of the identified network by applying the offset-list. The value 7000000 is added to the metric of the route.
R8(config)#router eigrp EIGRP_NAMED
R8(config-router)#address-family ipv4 unicast autonomous-system 1
R8(config-router-af)#topology base
R8(config-router-af-topology)#offset-list ACL_10200340 in 7000000 gigabitethernet0/0
Verification
The configuration of the offset-list can be verified by the following series of commands.
As can be observed in the following traceroute output, the change in metrics of the successor path causes the feasible successor to become the successor path.
R8#traceroute 10.200.34.1
Type escape sequence to abort.
Tracing the route to 10.200.34.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.100.1.17 52 msec 16 msec 16 msec
2 10.0.16.1 16 msec 32 msec 60 msec
3 10.200.13.2 36 msec * 56 msec
The RIB and topology table confirm that the route that was previously the feasible successor is now the new successor path.
R8#show ip route 10.200.34.0
Routing entry for 10.200.34.0/30
Known via "eigrp 1", distance 90, metric 163840, type internal
Redistributing via eigrp 1
Last update from 10.100.1.17 on FastEthernet4/1, 00:16:22 ago
Routing Descriptor Blocks:
* 10.100.1.17, from 10.100.1.17, 00:16:22 ago, via FastEthernet4/1
Route metric is 163840, traffic share count is 1
Total delay is 220 microseconds, minimum bandwidth is 100000 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 3
R8#show ip eigrp topology 10.200.34.0/30
EIGRP-IPv4 VR(EIGRP_NAMED) Topology Entry for AS(1)/ID(10.8.14.1) for 10.200.34.0/30
State is Passive, Query origin flag is 1, 1 Successor(s), FD is 20971520, RIB is 163840
Descriptor Blocks:
10.100.1.17 (FastEthernet4/1), from 10.100.1.17, Send flag is 0x0
Composite metric is (20971520/14417920), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 220000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 10.200.34.1
10.100.1.18 (FastEthernet4/1), from 10.100.1.18, Send flag is 0x0
Composite metric is (21626880/15073280), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 230000000 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 4
Originating router is 10.200.34.1
10.100.1.6 (GigabitEthernet0/0), from 10.100.1.6, Send flag is 0x0
Composite metric is (22073280/21417920), route is Internal
Vector metric:
Minimum bandwidth is 100000 Kbit
Total delay is 236811524 picoseconds
Reliability is 255/255
Load is 1/255
Minimum MTU is 1500
Hop count is 3
Originating router is 10.200.34.1
R8#
The offset-list configuration can be confirmed from the output of the show ip protocols command.
R8#show ip protocol
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is (route-map) RM_DENY_19216800
Incoming routes in GigabitEthernet0/0 will have 7000000 added to metric if on list ACL_10200340
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 VR(EIGRP_NAMED) Address-Family Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0 K6=0
Metric rib-scale 128
Metric version 64bit
NSF-aware route hold timer is 240
Router-ID: 10.8.14.1
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Total Prefix Count: 26
Total Redist Count: 0
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.8.0.0/16
10.100.1.16/28
10.100.0.0/23
Routing Information Sources:
Gateway Distance Last Update
10.100.1.7 90 00:16:47
10.100.1.6 90 00:16:47
10.100.1.20 90 00:16:47
10.100.1.18 90 00:16:47
10.100.1.17 90 00:16:47
Distance: internal 90 external 170
R8#
Modifying the EIGRP Administrative Distance
By default, the Administrative Distance for EIGRP internal routes is 90, external routes (routes redistributed into EIGRP) 170 and summary routes is 5. The default administrative distance in EIGRP can be modified for routes that are internal, external or per route. If the AD of one or more routes is modified, EIGRP's Diffusing Update ALgorith (DUAL) is executed to recalculate the best path. The EIGRP neighbor relationship may be reset as well. EIGRP supports the modification of the administrative distance of the following:
- All internal and external routes
- Routes from specific neighbors
- Specific routes
- Summary routes
Modifying the AD of Internal and External Routes
The EIGRP default administrative distance for internal and external routes
can be modified using the distance <internal> <external> command:
For EIGRP classic-mode, the AD for internal routes is modified to 70 and external routes to 105.
R4(config)#router eigrp 1
R4(config-router)#distance eigrp 70 105
For EIGRP named-mode, the AD modifications are implemented under address-family topology configuration mode:
R1(config)#router eigrp EIGRP_NAMED
R1(config-router)#address-family ipv4 unicast autonomous-system 1
R1(config-router-af)#topology base
R1(config-router-af-topology)#distance eigrp 70 105
Modifying AD for Routes from Specific Neighbors
The AD for all routes from a specific EIGRP peer can be modified using the command:
distance <1-255> <source-ip-address> <wildcard-mask>
where source-ip-address is the EIGRP neighbor IP address.
R1(config)#router eigrp EIGRP_NAMED
R1(config-router)#address-family ipv4 unicast autonomous-system 1
R1(config-router-af)#topology base
R1(config-router-af-topology)#distance 60 192.168.12.0 0.0.0.3
Modifying the AD of Specific Routes
The AD for specific routes can be modified by appending an access control list (ACL) to the command to modify the AD of all routes from a specific EIGRP peer. The specific routes whose AD are to be modified are identified using the permit statement of the ACL.
R7(config)#ip access-list standard ACL_AD_10.1.32.0/22
R7(config-std-nacl)#permit 10.1.32.0 0.0.2.255
R7(config-std-nacl)#exit
R7(config)#router eigrp 1
R7(config-router)#distance 89 10.255.254.5 0.0.0.0 ACL_AD_10.1.32.0/22
Verification of the above configurations can be done using the command
show ip protocols
R7#show ip protocols
*** IP Routing is NSF aware ***
Routing Protocol is "eigrp 1"
Outgoing update filter list for all interfaces is not set
Incoming update filter list for all interfaces is not set
Default networks flagged in outgoing updates
Default networks accepted from incoming updates
EIGRP-IPv4 Protocol for AS(1)
Metric weight K1=1, K2=0, K3=1, K4=0, K5=0
NSF-aware route hold timer is 240
Router-ID: 7.7.7.7
Topology : 0 (base)
Active Timer: 3 min
Distance: internal 90 external 170
Maximum path: 4
Maximum hopcount 100
Maximum metric variance 1
Automatic Summarization: disabled
Maximum path: 4
Routing for Networks:
10.255.2.0/30
10.255.2.5/32
10.255.254.2/32
10.255.254.4/30
Routing Information Sources:
Gateway Distance Last Update
10.255.254.1 90 00:00:32
10.255.254.5 89 00:00:32
10.255.2.6 90 00:00:32
10.255.2.2 90 00:00:32
Distance: internal 90 external 170
Address Wild mask Distance List
10.255.254.5 0.0.0.0 89 ACL_AD_10.1.32.0/22
Modifying the AD of Summary Routes
The AD of summary routes can be modified using the command summary-metric
. This command can both modify the metrics of a summary route as well as AD using
the distance modifier.
summary-metric <summary-address/subnetmask> distance <AD>.
Floating Summary Route
A floating summary route is created by configuring a default route and an administrative
distance at the interface level or address family interface level. It is configured using the
classical EIGRP interface command ip summary-address eigrp or
EIGRP named-mode af-interface command summary-address.
The configuration of a default summary route on an upstream router blocks the advertisement of more specific routes to downstream routers by intermediate routers. This problem can be resolved by configuration of a floating summary route. On the upstream router that advertised the default summary route, an AD greater than the default EIGRP AD is added to the floating summary route.
R4(config)#interface g1/0
R4(config-if)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0 252
On some IOS versions, adding the AD to a ip summary-address eigrp
command is deprecated. The EIGRP router-mode command
summary-metric is instead used:
R4(config)#interface g1/0
R4(config-if)#ip summary-address eigrp 1 0.0.0.0 0.0.0.0 252
%EIGRP: summary-address accepted but distance option deprecated; use summary-metric command for distance.
R4(config-if)#router eigrp 1
R4(config-router)#summary-metric 0.0.0.0 0.0.0.0 distance 252
Troubleshooting AD Issues
If higher metric EIGRP routes are installed into the routing table in preference to lower metric EIGRP routes, it is more likely that these higher metric routes have their AD lower than the lower metric EIGRP routes as well as the default EIGRP protocol AD.
Authentication
Authentication is a mechanism for ensuring that only authorized routers are eligible to become EIGRP neighbors. Authentication prevents a rogue router from joining the network and introducing invalid routes, accidentally or maliciously. A precomputed hash is generated from a configured key chain key number and password. The hash is included with all EIGRP packets. When the packet is received, the receiving router also calculates the hash on the packet. If the two hash values match, the packet is accepted. EIGRP authentication does not encrypt the contents of the routing update packets.
EIGRP supports two types of authentication: MD5 and HMAC-SHA-256. MD5 authentication is implemented in both classic and named EIGRP configuration modes. It utilizes keychains and supports automatic key rotation. SHA authentication is supported only by named EIGRP. In older IOS versions, SHA authentication did not support key chains configuration and key rotation. The password was configured under interface configuration. In newer IOS images, HMAC-SHA configuration is supported in key chain configuration.
Key Chains
EIGRP authentication utilizes key chains. Key chains act as a sort of ring holding multiple keys. Each key is configured with a key ID and a key string. Each key can optionally be configured with send-lifetimes and accept-lifetimes:
- send-lifetime: sets the time period during which an authentication key on a key chain is valid to be sent.
- accept-lifetime: sets the time period during which the authentication key on a key chain is received as valid.
Step 1: Create the keychain using the command key chain <key-chain-name>.
R7(config)#key chain EIGRP_KEYCHAIN
Step 2: Identify the key sequence by using the command key <0 - 2147483647>.
Note that the key number of the valid key must match on both EIGRP peers.
R7(config-keychain)#key 1
Step 3: Specify the preshared password by using the command
key-string <password>.
When defining the password, note that white space counts as a character.
Keychains support automatic key rotation.
R7(config-keychain-key)#key-string CISCO321
Step 4: (Optional) Configure the validity period of the key(s). It is important to ensure the accuracy of the clock; this can be done through configuration of NTP.
R7(config-keychain-key)#accept-lifetime 09:40:00 Oct 3 2021 duration 3600
R7(config-keychain-key)#send-lifetime 09:40:00 Oct 3 2021 duration 3600
R7(config-keychain-key)#key 2
R7(config-keychain-key)#key-string CISCO3210
R7(config-keychain-key)#accept-lifetime 10:20:00 Oct 3 2021 duration 864000
R7(config-keychain-key)#send-lifetime 10:20:00 Oct 3 2021 duration 864000
R7(config-keychain-key)#end
R7(config-router-af-interface)#do show clock
*09:37:53.891 UTC Sun Oct 3 2021
The key duration value is in seconds. In the above configuration, the key with ID 1 is valid for one hour. The second key , with key ID 2 is valid for ten (10) days.
The command show key chain can be used to verify the configured keychain.
R7#show key chain
Key-chain EIGRP_KEYCHAIN:
key 1 -- text "CISCO321"
accept lifetime (09:40:00 UTC Oct 3 2021) - (3600 seconds) [valid now]
send lifetime (09:40:00 UTC Oct 3 2021) - (3600 seconds) [valid now]
key 2 -- text "CISCO3210"
accept lifetime (10:20:00 UTC Oct 3 2021) - (864000 seconds)
send lifetime (10:20:00 UTC Oct 3 2021) - (864000 seconds)
Automatic Key-Rotation
A key chain supports multiple key numbers. A router always sends the lowest valid key if more than one key is valid to be sent. The key number's validity is based on time. Additionally, when configuring multiple keys, ensure that the validity periods of the keys overlap by a significant amount of time; the second key should be valid to be sent and received before the expiry of the first key. This ensures that at least more than one key is valid during the transition from one key to another. If one key expires and another is not valid, the neighborship may be lost resulting in route loss for some prefixes.
Classical EIGRP Authentication
Classic mode EIGRP supports only MD5 authentication. To enable MD5 authentication, follow these steps:
- Specify the key chain under the interface configuration
sub-mode:
R1(config)#interface gigabitethernet 0/0
R1(config-if)#ip authentication key-chain eigrp 1 EIGRP_KEYCHAIN - Enable MD5 authentication for EIGRP under the interface:
R1(config-if)#ip authentication mode eigrp 1 md5
R1(config-if)#do show ip eigrp interface detail g0/0
EIGRP-IPv4 Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 0 0/0 0/0 0 0/0 160 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 29/0
Hello's sent/expedited: 2332/2
Un/reliable mcasts: 0/26 Un/reliable ucasts: 19/11
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 6 Out-of-sequence rcvd: 0
Topology-ids on interface - 0
Authentication mode is md5, key-chain is "EIGRP_KEYCHAIN"
R1(config-if)#
R1(config-if)#do show key chain
Key-chain EIGRP_KEYCHAIN:
key 1 -- text "CISCO321"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
key 2 -- text "CISCO3210"
accept lifetime (always valid) - (always valid) [valid now]
send lifetime (always valid) - (always valid) [valid now]
R1(config-if)#
Named EIGRP Peer Authentication
Named mode configuration of EIGRP supports MD5 and SHA authentication.
MD5 uses same global key chains as classic. SHA authentication uses a static key configuration. Authentication is
configured under af-interface default to enable authentication for all EIGRP-enabled interfaces
or under a specific interface using the command af-interface <interface-id>.
Authentication settings configured under a specific interface override configuration settings under the default interface.
SHA digest is more secure than MD5 due to the key chain length.
The named-mode configuration places the configurations under the EIGRP interface
sub-mode configuration using either af-interface default
command or interface specific command af-interface <interface-id>.
EIGRP SHA Authentication Configuration
SHA Authentication is configured under af-interface mode of the appropriate interface or default interface to apply SHA authentication to all EIGRP-participating interfaces. Newer IOS releases support key chain configuration for SHA authentication.
R8(config)#router eigrp EIGRP_8
R8(config-router)#address-family ipv4 unicast autonomous-system 1
R8(config-router-af)#af-interface fastethernet 4/1
R8(config-router-af-interface)#authentication mode hmac-sha-256 CISCO123
R8(config-router-af-interface)#end
*Oct 3 09:11:29.335: %SYS-5-CONFIG_I: Configured from console by consoleo
R8#show ip eigrp interface detail fastethernet4/1
EIGRP-IPv4 VR(EIGRP_8) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Fa4/1 2 0/0 0/0 138 0/1 208 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 13/2
Hello's sent/expedited: 367/6
Un/reliable mcasts: 0/10 Un/reliable ucasts: 25/14
Mcast exceptions: 3 CR packets: 3 ACKs suppressed: 0
Retransmissions sent: 4 Out-of-sequence rcvd: 1
Topology-ids on interface - 0
Authentication mode is HMAC-SHA-256, key-chain is not set
R8#
EIGRP MD5 Authentication Configuration
Authentication using MD5 digest is implemented using key chains. A key chain can be configured as shown below:
R7(config-keychain)#router eigrp EIGRP_R7
R7(config-router)#address-family ipv4 unicast autonomous-system 1
R7(config-router-af)#af-interface g0/0
R7(config-router-af-interface)#authentication key-chain EIGRP_KEYCHAIN
R7(config-router-af-interface)#authentication mode md5
R7#show ip eigrp interface detail g0/0
EIGRP-IPv4 VR(EIGRP_R7) Address-Family Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 2 0/0 0/0 138 0/0 524 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 30/1
Hello's sent/expedited: 809/15
Un/reliable mcasts: 0/18 Un/reliable ucasts: 37/70
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 53 Out-of-sequence rcvd: 3
Topology-ids on interface - 0
Authentication mode is md5, key-chain is "EIGRP_KEYCHAIN"
Troubleshooting Authentication
Debugging EIGRP packets can help identify EIGRP authentication problems.
R6#debug eigrp packets
(UPDATE, REQUEST, QUERY, REPLY, HELLO, IPXSAP, PROBE, ACK, STUB, SIAQUERY, SIAREPLY)
EIGRP Packet debugging is on
R6#
*Oct 3 09:03:24.191: EIGRP: Received HELLO on Gi0/0 - paklen 20 nbr 10.100.0.2
*Oct 3 09:03:24.191: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oc
R6#t 3 09:03:24.195: {type = 1, length = 12}
*Oct 3 09:03:24.199: {vector = {
*Oct 3 09:03:24.199: {01000100 0000000F}
*Oct 3 09:03:24.211: }
*Oct 3 09:03:24.211: {type = 4, length = 8}
*Oct 3 09:03:24.211: {vector = {
*Oct 3 09:03:24.211: {0A000200}
*Oct 3 09:03:24.219: }
*Oct 3 09:03:24.219: EIGRP: Received HELLO on Gi1/0 - paklen 20 nbr 10.0.26.1
*Oct 3 09:03:24.223: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 3 09:03:24.227: {type = 1, length = 12}
*Oct 3 09:03:24.227: {vector = {
*Oct 3 09:03:24.227: {01000100 0000000F}
*Oct 3 09:03:24.239: }
*Oct 3 09:03:24.239: {type = 4, length = 8}
*Oct 3 09:03:24.243: {vector = {
*Oct 3 09:03:24.243: {0A000200}
*Oct 3 09:03:24.247: }
*Oct 3 09:03:25.091: EIGRP: Fa3/1: ignored packet from 10.100.1.2, opcode = 5 (authentication off or key-chain missing)
*Oct 3 09:03:25.239: EIGRP: Received HE
R6#LLO on Gi0/0 - paklen 20 nbr 10.100.0.3
*Oct 3 09:03:25.243: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
*Oct 3 09:03:25.247: {type = 1, length = 12}
*Oct 3 09:03:25.247: {vector = {
*Oct 3 09:03:25.247: {01000100 0000000F}
*Oct 3 09:03:25.259: }
*Oct 3 09:03:25.259: {type = 4, length = 8}
*Oct 3 09:03:25.259: {vector = {
*Oct 3 09:03:25.263: {0A000200}
*Oct 3 09:03:25.267: }
*Oct 3 09:03:25.271: EIGRP: Fa3/1: ignored packet from 10.100.1.3, opcode = 5 (authentication off or key-chain missing)
*Oct 3 09:03:25.511: EIGRP: Fa3/1: ignored packet from 10.100.1.4, opcode = 5 (authentication off or key-chain missing)
*Oct 3 09:03:26.259: EIGRP: Sending HELLO on Fa3/0 - paklen 20
*Oct 3 09:03:26.259: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Oct 3 09:03:26.263: {type = 1, length = 12}
*Oct 3 09:03:26.263: {vector = {
*Oct 3 09:03:26.263: {0100
R6#0100 0000000F}
*Oct 3 09:03:26.275: }
*Oct 3 09:03:26.275: {type = 4, length = 8}
*Oct 3 09:03:26.279: {vector = {
*Oct 3 09:03:26.279: {0A000200}
*Oct 3 09:03:26.287: }
*Oct 3 09:03:26.331: EIGRP: Sending HELLO on Gi0/0 - paklen 20
*Oct 3 09:03:26.331: AS 1, Flags 0x0:(NULL), Seq 0/0 interfaceQ 0/0 iidbQ un/rely 0/0
*Oct 3 09:03:26.335: {type = 1, length = 12}
*Oct 3 09:03:26.335: {vector = {
*Oct 3 09:03:26.339: {01000100 0000000F}
*Oct 3 09:03:26.347: }
*Oct 3 09:03:26.351: {type = 4, length = 8}
*Oct 3 09:03:26.351: {vector = {
*Oct 3 09:03:26.351: {0A000200}
*Oct 3 09:03:26.359: }
Additional commands that help in troubleshooting include:
show ip eigrp interface detailshow key chain
EIGRP in Wide Area Networks
IP Bandwidth Percentage
The interface parameter command ip bandwidth-percent eigrp <as-number percentage>
changes the EIGRP available bandwidth for a link on EIGRP classic configuration.
The available bandwidth for EIGRP is modified under the af-interface default sub-mode or the af-interface interface-id
sub-mode with the command bandwidth-percent percentage in a named-mode configuration.
In the following example, the bandwidth restriction for EIGRP is 20%.
R1(config)#interface g0/0
R1(config-if)#ip bandwidth-percent eigrp 1 20
R1(config-if)#do show ip eigrp interface detail g0/0
EIGRP-IPv4 Interfaces for AS(1)
Xmit Queue PeerQ Mean Pacing Time Multicast Pending
Interface Peers Un/Reliable Un/Reliable SRTT Un/Reliable Flow Timer Routes
Gi0/0 1 0/0 0/0 58 0/0 228 0
Hello-interval is 5, Hold-time is 15
Split-horizon is enabled
Next xmit serial
Packetized sent/expedited: 3/0
Hello's sent/expedited: 6910/2
Un/reliable mcasts: 0/5 Un/reliable ucasts: 4/2
Mcast exceptions: 0 CR packets: 0 ACKs suppressed: 0
Retransmissions sent: 1 Out-of-sequence rcvd: 2
Topology-ids on interface - 0
Interface BW percentage is 20
Authentication mode is not set
Troubleshooting
EIGRP Configured But not Running
Issue the command no shut in EIGRP router mode to enable a
previously shutdown EIGRP instance.
EIGRP over VRF-Lite
EIGRP supports routing over a Virtual Routing and Forwarding - Lite (VRF-Lite) context. This routing is contextual to the router that it is configured on. EIGRP over VRF-Lite is enabled in EIGRP named mode only.
To configure EIGRP over VRF-Lite:
- Initialize the appropriate address family using the command
address-family ipv4 vrf <vrf-name> autonomous-system <as-number>.
EIGRP VRF-Lite Verification
The configuration and operational state of EIGRP VRF-Lite can be verified using the following commands:
show ip eigrp vrf <vrf-name> interfacesshow ip eigrp vrf <vrf-name> neighborsshow ip eigrp vrf <vrf-name> topology [<network> <prefix-length>]show ip route vrf <vrf-name>ping vrf <vrf-name> <ip-address>traceroute vrf <vrf-name> <ip-address>
EIGRPv6
EIGRP packets use IP protocol 88 for both IPv4 and IPv6. Routers communicate with each other using the interface's IPv6 link-local address as the source. The destination may be either unicast link-local or multicast link-local scoped address FF02::A.
| EIGRP Packet | Source | Destination | Purpose |
| Hello | Link-local address | FF02::A | Neighbor discovery and keepalive |
| Acknowledgment | Link-local address | Link-local address | Acknowledges receipt of an update |
| Query | Link-local address | FF02::A | Request for route information during a topology change event |
| Reply | Link-local address | Link-local address | A response to a query message |
| Update | Link-local address | Link-local address | Adjacency forming |
| Update | Link-local address | FF02::A | Topology change |
Configuration
EIGRPv6 supports two configuration modes: classic and named.
Classic mode
Original mode for configuration of EIGRPv6.
- Configure EIGRPv6 process using command
ipv6 router eigrp <autonomous-system-number> - Define the router ID using the command
eigrp router-id <x.x.x.x> - Enable EIGRPv6 process on interface using interface command
ipv6 eigrp <autonomous-system-number>
Named mode
Similar to IPv4 EIGRP named-mode configuration, is implemented in the following steps:
- Configure the EIGRPv6 routing process using the command
router eigrp <process-name> - Define the IPv6 address family and autonomous system number using the command
address-family ipv6 autonomous-system <autonomous-system-number>. - Assign the router-id using the command
eigrp router-id <ip-address>.
Like IPv4 named-mode configuration, EIGRPv6 uses hierarchical configuration under the address-family, topology base and interface modes.
Verification
Traditional EIGRP verification commands for IPv4 are the same for EIGRPv6.
show ipv6 eigrp interfaces
Displays EIGRPv6 interfaces
show ipv6 eigrp neighbors
show ipv6 protocols
Displays the current state of active routing protocol.
Summarization
Manual summarization is accomplished using the commands:
- Classic-mode:
ipv6 summary-address eigrp <autonomous-system-number> ipv6-prefix/prefix-length. - Named-mode:
summary-address <ipv6-address> /<prefix-length>under theaf-interfacemode.
Default route advertisement
A default route can be advertised by placing the default route ::/0 as a summary address on
an interface ipv6 summary-address eigrp 10 ::/0.
