Section 36 – EIGRP

Section 36 Tasks

• Read today’s lesson notes (below)
• Review yesterday’s lesson notes
• Complete today’s lab
• Read the ICND2 cram guide

Enhanced Interior Gateway Routing Protocol (EIGRP) is a proprietary Interior Gateway Protocol (IGP) that was developed by Cisco. EIGRP includes traditional Distance Vector characteristics, such as split horizon, as well as characteristics that are similar to those used by Link State routing protocols, such as incremental updates.

Although EIGRP has Link State routing protocol characteristics, EIGRP falls under the Distance Vector routing protocol classification and is referred to as an advanced Distance Vector routing protocol instead. EIGRP runs directly over IP using protocol number 88.

Today you will learn about the following:

• Cisco EIGRP overview and fundamentals
• EIGRP configuration fundamentals
• EIGRP messages
• EIGRP neighbour discovery and maintenance
• Metrics, DUAL, and the topology table
• Equal cost and unequal cost load sharing
• Default routing using EIGRP
• Split horizon in EIGRP networks
• EIGRP stub routing
• EIGRP route summarisation
• Understanding passive interfaces
• Understanding the use of the EIGRP router ID
• EIGRP logging and reporting

This lesson maps to the following CCNA syllabus requirements:

• Configure and verify EIGRP (single AS)
• Feasible Distance / Feasible Successor routes / Reported Distance / Advertised Distance
• Feasibility condition
• Metric composition
• Router ID
• Auto summary
• Path selection
  • Load balancing
  • Equal
• Unequal Passive interfaces

Cisco EIGRP Overview and Fundamentals

Cisco developed Enhanced IGRP to overcome some of the limitations of its proprietary Distance Vector routing protocol, Interior Gateway Routing Protocol (IGRP). IGRP offered improvements over Routing Information Protocol (RIP), such as support for an increased number of hops; however, IGRP still succumbed to the traditional Distance Vector routing protocol limitations, which included the following:

• Sending full periodic routing updates
• A hop limitation
• The lack of VLSM support
• Slow convergence
• The lack of loop prevention mechanisms

Unlike the traditional Distance Vector routing protocols, which send their neighbours periodic routing updates that contain all routing information, EIGRP sends non-periodic incremental routing updates to distribute routing information throughout the routing domain. The EIGRP incremental updates are sent when there is a change in the network topology.

By default, RIP (a former CCNA-level topic) has a hop-count limitation of up to 15 hops, which makes RIP suitable only for smaller networks. EIGRP has a default hop-count limitation of 100; however, this value can be manually adjusted by the administrator using the metric maximumhops <1-255> router configuration command when configuring EIGRP. This allows EIGRP to support networks that contain hundreds of routers, making it more scalable and better suited for larger networks.

Enhanced IGRP uses two unique Type/Length/Value (TLV) triplets to carry route entries. These TLVs are the Internal EIGRP Route TLV and the External EIGRP Route TLV, which are used for internal and external EIGRP routes, respectively. Both TLVs include an 8-bit Prefix Length field that specifies the number of bits used for the subnet mask of the destination network. The information that is contained in this field allows EIGRP to support variably subnetted networks.

Enhanced IGRP converges much faster than the traditional Distance Vector routing protocols. Instead of relying solely on timers, EIGRP uses information contained in its topology table to locate alternate paths. EIGRP can also query neighbouring routers for information if an alternate path is not located in the local router’s topology table. The EIGRP topology table will be described in detail later in this module.

In order to ensure that there are loop-free paths through the network, EIGRP uses the Diffusing Update Algorithm (DUAL), which is used to track all routes advertised by neighbours and then select the best loop-free path to the destination network. DUAL is a core EIGRP concept that will be described in detail later in this module.

EIGRP Configuration Fundamentals

Enhanced IGRP is enabled in Cisco IOS software using the router eigrp [ASN] global configuration command. The [ASN] keyword designates the EIGRP autonomous system number (ASN). This is a 32-bit integer between 1 and 65535. In addition to other factors, which will be described later in this lesson, routers running EIGRP must reside within the same autonomous system to form a neighbour relationship successfully. Following the configuration of the router eigrp [ASN] global configuration command, the router transitions to EIGRP Router Configuration mode wherein you can configure parameters pertaining to EIGRP. The configured ASN can be verified in the output of the show ip protocols command, as follows:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
...

[Truncated Output]

In addition to the show ip protocols command, the show ip eigrp neighbors command prints information on all known EIGRP neighbours and their respective autonomous systems. This command, and its available options, will be described in detail later in this module. On routers running multiple instances of EIGRP, the show ip eigrp [ASN] command can be used to view information pertaining only to the autonomous system that is specified in this command. The use of this command is illustrated in the following output:

R1#show ip eigrp 150 ?
interfaces  IP-EIGRP interfaces
neighbors   IP-EIGRP neighbors
topology    IP-EIGRP topology table
traffic     IP-EIGRP traffic statistics

In the output above, 150 is the ASN. The default in Cisco IOS software is to print information on all EIGRP instances if an autonomous system is not specified with any show ip eigrp commands.

Once in Router Configuration mode, the network command is used to specify the network(s) (interfaces) for which EIGRP routing will be enabled. When the network command is used and a major classful network is specified, the following actions are performed on the EIGRP-enabled router:

• EIGRP is enabled for networks that fall within the specified classful network range.
• The topology table is populated with these directly connected subnets.
• EIGRP Hello packets are sent out of the interfaces associated with these subnets.
• EIGRP advertises the network(s) to EIGRP neighbours in Update messages.
• Based on the exchange of messages, EIGRP routes are then added to the IP routing table.

For example, assume that the router has the following Loopback interfaces configured:

• Loopback0 – IP Address 10.0.0.1/24
• Loopback1 – IP Address 10.1.1.1/24
• Loopback2 – IP Address 10.2.2.1/24
• Loopback3 – IP Address 10.3.3.1/24

If EIGRP is enabled for use and the major classful 10.0.0.0/8 network is used in conjunction with the network router configuration command, all four Loopback interfaces are enabled for EIGRP routing. This is illustrated in the following output:

R1#show ip eigrp interfaces
IP-EIGRP interfaces for process 150
Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface      Peers Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo0             0        0/0         0       0/10           0           0
Lo1             0        0/0         0       0/10           0           0
Lo2             0        0/0         0       0/10           0           0
Lo3             0        0/0         0       0/10           0           0

You can use the show ip protocols command to verify that EIGRP is enabled for the major classful 10.0.0.0/8 network. The output of this command is illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

The EIGRP topology table can be viewed using the show ip eigrp topology command. The output of this command is illustrated below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.3.3.0/24, 1 successors, FD is 128256 via Connected, Loopback3
P 10.2.2.0/24, 1 successors, FD is 128256 via Connected, Loopback2
P 10.1.1.0/24, 1 successors, FD is 128256 via Connected, Loopback1
P 10.0.0.0/24, 1 successors, FD is 128256 via Connected, Loopback0

NOTE: The topology table, EIGRP Hello packets, and Update messages are described in detail later in this module. The focus of this section is restricted to EIGRP configuration implementation.

Using the network command to specify a major classful network allows multiple subnets that fall within the classful network range to be advertised at the same time with minimal configuration. However, there may be situations where administrators may not want all of the subnets within a classful network to be enabled for EIGRP routing. For example, referencing the Loopback interfaces configured on R1 in the previous example, assume that you want EIGRP routing enabled only for the 10.1.1.0/24 and 10.3.3.0/24 subnets, and not for the 10.0.0.0/24 and 10.2.2.0/24 subnets. While it appears that this would be possible if you specified the networks (i.e., 10.1.1.0 and 10.3.3.0) when using the network command, Cisco IOS software still converts these statements to the major classful 10.0.0.0/8 network, as illustrated below:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.1.0
R1(config-router)#network 10.3.3.0
R1(config-router)#exit

Despi te  the  confi guration  above,  the  show ip protocols  command  reveal s  the  fol lowing:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

NOTE: A common misconception is that disabling the EIGRP automatic summarisation feature addresses this issue; however, this has nothing to do with the auto-summary command. For example, assume that you issued the no auto-summary command to the configuration used in the previous example, as follows:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.1.0
R1(config-router)#network 10.3.3.0
R1(config-router)#no auto-summary
R1(config-router)#exit

The show ip protocols command still shows that EIGRP is enabled for network 10.0.0.0/8, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

In order to provide more granular control of the networks that are enabled for EIGRP routing, Cisco IOS software supports the use of wildcard masks in conjunction with the network statement when configuring EIGRP. The wildcard mask operates in a manner similar to the wildcard mask used in ACLs and is independent of the subnet mask for the network.

As an example, the command network 10.1.1.0 0.0.0.255 would match the 10.1.1.0/24 network, the 10.1.1.0/26 network, and the 10.1.1.0/30 network. Referencing the Loopback interfaces configured in the previous output, R1 would be configured as follows to enable EIGRP routing for the 10.1.1.0/24 and 10.3.3.0/24 subnets, and not for the 10.0.0.0/24 subnet or the 10.2.2.0/24 subnet:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.1.0 0.0.0.255
R1(config-router)#network 10.3.3.0 0.0.0.255
R1(config-router)#exit

This configuration can be validated using the show ip protocols command, as follows:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    10.1.1.0/24
    10.3.3.0/24
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

Additionally, the show ip eigrp interfaces command can be used to validate that EIGRP routing has been enabled only for Loopback1 and Loopback3:

R1#show ip eigrp interfaces
IP-EIGRP interfaces for process 150
Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface     Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Lo1            0        0/0         0       0/10           0           0
Lo3            0        0/0         0       0/10           0           0

As illustrated in the output above, EIGRP routing is enabled only for Loopback1 and Loopback3 because of the wildcard mask configuration.

It is important to remember that the network command can be configured using the subnet mask, rather than the wildcard mask. When this is the case, Cisco IOS software inverts the subnet mask and the command is saved using the wildcard mask. For example, referencing the same Loopback interfaces on the router, R1 could also be configured as follows:

R1(config-router)#router eigrp 150
R1(config-router)#network 10.1.1.0 255.255.255.0
R1(config-router)#network 10.3.3.0 255.255.255.0
R1(config-router)#exit

Based on this configuration, the following is entered in the running configuration (I’ve used a pipe to drill down to the part of config I’m interested in):

R1#show running-config | begin router eigrp
router eigrp 150
network 10.1.1.0 0.0.0.255
network 10.3.3.0 0.0.0.255
auto-summary

You can see by the above configuration that you can use pipes with show commands in order to get more granularity. This will be a familiar concept to anyone with previous programming knowledge.

If a specific address on the network is used, in conjunction with the wildcard mask, Cisco IOS software performs a logical AND operation to determine the network that will be enabled for EIGRP. For example, if the network 10.1.1.15 0.0.0.255 command is issued, Cisco IOS software performs the following actions:

• Inverts the wildcard mask to the subnet mask value of 255.255.255.0
• Performs a logical AND operation
• Adds the network 10.1.1.0 0.0.0.255 command to the configuration

The network configuration used in this example is illustrated in the following output:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.1.15 0.0.0.255
R1(config-router)#exit

Based on this, the running configuration on the router displays the following:

R1#show running-config | begin router eigrp
router eigrp 150
network 10.1.1.0 0.0.0.255
auto-summary

If a specific address on the network is used in conjunction with the subnet mask, the router performs the same logical AND operation and adds the network command to the running configuration using the wildcard mask format. This is illustrated in the configuration below:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.1.15 255.255.255.0
R1(config-router)#exit

Based on this configuration, the following is added to the current configuration on the router:

R1#show running-config | begin router eigrp
router eigrp 150
network 10.1.1.0 0.0.0.255
auto-summary

As illustrated in the configuration above, the use of either the wildcard mask or the subnet mask results in the same operation and network statement configuration in Cisco IOS software.

Real-World Implementation

When configuring EIGRP in production networks, it is common practice to use a wildcard mask of all zeros or a subnet mask of all 1s. For example, the network 10.1.1.1 0.0.0.0 and network 10.1.1.1 255.255.255.255 commands perform the same actions. Using all zeros in the wildcard mask or all ones in the subnet mask configures Cisco IOS software to match an exact interface address, regardless of the subnet mask configured on the interface itself. Either one of these commands would match interfaces configured with the 10.1.1.1/8, 10.1.1.1/16, 10.1.1.1/24, and 10.1.1.1/30 address, for example. The use of these commands is illustrated in the following output:

R1(config)#router eigrp 150
R1(config-router)#network 10.0.0.1 0.0.0.0
R1(config-router)#network 10.1.1.1 255.255.255.255
R1(config-router)#exit

The show ip protocols command verifies that the configuration of both network statements is treated in a similar manner on the router, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.1/32
    10.1.1.1/32
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

When a subnet mask with all ones or a wildcard mask with all zeros is used, EIGRP is enabled for the specified (matched) interface and the network the interface resides on is advertised. In other words, EIGRP will not advertise the /32 address in the output above but, instead, the actual network based on the subnet mask configured on the matched interface. The use of this configuration is independent of the subnet mask configured on the actual interface matched.

EIGRP Messages

This section describes the different types of messages used by EIGRP. However, before delving into the specifics of the different message types, it is important to have a solid understanding of the EIGRP packet header, wherein these messages are contained.

EIGRP Packet Header

Although going into specifics on the EIGRP packet formats is beyond the scope of the CCNA exam requirements, a fundamental understanding of the EIGRP packet header is important in order to understand completely the overall operation of the EIGRP routing protocol. Figure 36.1 below illustrates the format of the EIGRP packet header:

Within the EIGRP packet header, the 4-bit Version field is used to indicate the protocol version. Current Cisco IOS images support EIGRP version 1.x. The 4-bit OPCode field specifies the EIGRP packet or message type. The different EIGRP packet types are each assigned a unique OPCode value, which allows them to be differentiated from other packet types. These messages will be described in detail later in this module.

The 24-bit Checksum field is used to run a sanity check on the EIGRP packet. This field is based on the entire EIGRP packet, excluding the IP header. The 32-bit Flags field is used to indicate an INIT either for a new EIGRP neighbour or for the Conditional Receive (CR) for EIGRP Reliable Transport Protocol (RTP). RTP and CR will be described in detail later in this module.

The 32-bit Sequence field specifies the sequence number used by EIGRP RTP to ensure orderly delivery of reliable packets. The 32-bit Acknowledgment field is used to acknowledge the receipt of an EIGRP reliable packet.

The 32-bit Autonomous System Number field specifies the ASN of the EIGRP domain. Finally, the 32-bit Type/Length/Value (TLV) triplet field is used to carry route entries and provides EIGRP DUAL information. EIGRP supports several different types of TLVs, with the most common being the following:

• The Parameters TLV, which has the parameters to establish neighbour relationships
• The Sequence TLV, which is used by RTP
• The Next Multicast Sequence TLV, which is used by RTP
• The EIGRP Internal Route TLV, which is used for internal EIGRP routes
• The EIGRP External Route TLV, which is used for external EIGRP routes

NOTE: You are not required to go into detail on the different EIGRP TLVs.

Figure 36.2 below illustrates the different fields as they appear in a wire capture of an EIGRP packet:

Within the EIGRP packet header, the 4-bit OPCode field is used to specify the EIGRP packet type or message. EIGRP uses different message or packet types, which are Hello packets, Acknowledgement packets, Update packets, Query packets, Reply packets, and Request packets. These packet types are described in detail in the following sections.

Hello Packets

Enhanced IGRP sends Hello packets once it has been enabled on a router for a particular network. These messages are used to identify neighbours and, once identified, serve or function as a keepalive mechanism between neighbours. EIGRP neighbour discovery and maintenance is described in detail later in this module.

Enhanced IGRP Hello packets are sent to the Link Local Multicast group address 224.0.0.10. Hello packets sent by EIGRP do not require an Acknowledgment to be sent confirming that they were received. Because they require no explicit acknowledgment, Hello packets are classified as unreliable EIGRP packets. EIGRP Hello packets have an OPCode of 5.

Acknowledgement Packets

An EIGRP Acknowledgment (ACK) packet is simply an EIGRP Hello packet that contains no data. Acknowledgement packets are used by EIGRP to confirm reliable delivery of EIGRP packets. The ACK packets are always sent to a Unicast address, which is the source address of the sender of the reliable packet, and not to the EIGRP Multicast group address. In addition, ACK packets will always contain a non-zero acknowledgment number. The ACK packet uses the same OPCode as the Hello packet because it is essentially a Hello packet that contains no information. The OPCode is 5.

Update Packets

Enhanced IGRP Update packets are used to convey reachability of destinations. In other words, Update packets contain EIGRP routing updates. When a new neighbour is discovered, Update packets are sent via Unicast so that the neighbour can build up its EIGRP topology table. In other cases, such as a link cost change, updates are sent via Multicast. It is important to know that Update packets are always transmitted reliably and always require explicit acknowledgement. Update packets are assigned an OPCode of 1. An EIGRP Update packet is illustrated in Figure 36.3 below:

NOTE: You are not required to go into detail on the information contained in EIGRP packets.

Query Packets

Enhanced IGRP Query packets are Multicast and are used to request reliable routing information. EIGRP Query packets are sent to neighbours when a route is not available and the router needs to ask about the status of the route for fast convergence. If the router that sends out a Query does not receive a response from any of its neighbours, it resends the Query as a Unicast packet to the non-responsive neighbour(s). If no response is received in 16 attempts, the EIGRP neighbour relationship is reset. This concept will be described in further detail later in this module. EIGRP Query packets are assigned an OPCode of 3.

Reply Packets

Enhanced IGRP Reply packets are sent in response to Query packets. The Reply packets are used to respond reliably to a Query packet. Reply packets are Unicast to the originator of the Query. The EIGRP Reply packets are assigned an OPCode of 4.

Request Packets

Enhanced IGRP Request packets are used to get specific information from one or more neighbours and are used in route server applications. These packet types can be sent via either Multicast or Unicast but are always transmitted unreliably. In other words, they do not require an explicit acknowledgment.

NOTE: While EIGRP Hello and ACK packets have been described as two individual packet types, it is important to remember that in some texts, EIGRP Hello and ACK packets are considered the same type of packet. This is because, as was stated earlier in this section, an ACK packet is simply an EIGRP Hello packet that contains no data.

The debug eigrp packets command may be used to print real-time debugging information on the different EIGRP packets described in this section. Keep in mind that this command also includes additional packets that are not described, as they are beyond the scope of the current CCNA exam requirements. The following output illustrates the use of this command:

R1#debug eigrp packets ?
  SIAquery  EIGRP SIA-Query packets
  SIAreply  EIGRP SIA-Reply packets
  ack       EIGRP ack packets
  hello     EIGRP hello packets
  ipxsap    EIGRP ipxsap packets
  probe     EIGRP probe 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>

The show ip eigrp traffic command is used to view the number of EIGRP packets sent and received by the local router. This command is also a powerful troubleshooting tool. For example, if the routing is sending out Hello packets but is not receiving any back, this could indicate that the intended neighbour is not configured, or even that an ACK may be blocking EIGRP packets. The following output illustrates this command:

R2#show ip eigrp traffic
IP-EIGRP Traffic Statistics for AS 150
Hellos sent/received: 21918/21922
Updates sent/received: 10/6
Queries sent/received: 1/0
Replies sent/received: 0/1
Acks sent/received: 6/10
SIA-Queries sent/received: 0/0
SIA-Replies sent/received: 0/0
Hello Process ID: 178
PDM Process ID: 154
IP Socket queue:   0/2000/2/0 (current/max/highest/drops)
Eigrp input queue: 0/2000/2/0 (current/max/highest/drops)

Table 36.1 summarises the EIGRP packets described in this section and whether they are sent unreliably or reliably:

Table 36.1 – EIGRP Packet Summary

EIGRP Neighbour Discovery and Maintenance

Enhanced IGRP may be configured to discover neighbouring routers dynamically (default) or via manual administrator configuration. Both methods, as well as other EIGRP neighbour-related topics, will be described in the following sections.

Dynamic Neighbour Discovery

Dynamic neighbour discovery is performed by sending EIGRP Hello packets to the destination Multicast group address 224.0.0.10. This is performed as soon as the network command is issued when configuring EIGRP on the router. In addition, as stated earlier, EIGRP packets are sent directly over IP using protocol number 88. Figure 36.4 below illustrates the basic EIGRP neighbour discovery and route exchange process:

Referencing Figure 36.4, upon initialisation, the EIGRP neighbours send Hello packets to discover other neighbours. The neighbours then exchange their full routing tables via full Updates. These Updates contain information about all known routes. Because Update packets are sent reliably, they must be explicitly acknowledged by the recipient.

After the neighbours have exchanged their routing information, they continue to exchange Hello packets to maintain the neighbour relationship. Additionally, the EIGRP neighbour routers will only send incremental updates to advise neighbours of status or routing changes. They will no longer send full Updates to neighbour routers.

It is important to understand that simply enabling EIGRP between two or more routers does not guarantee that a neighbour relationship will be established. Instead, some parameters must match in order for the routers to become neighbours. The EIGRP neighbour relationship may not establish due to any of the following circumstances:

• Mismatched EIGRP authentication parameters (if configured)
• Mismatched EIGRP K values
• Mismatched EIGRP autonomous system number
• Using secondary addresses for EIGRP neighbour relationships
• The neighbours are not on a common subnet

While the show ip eigrp neighbors command does not differentiate between dynamically and statically configured neighbours, the show ip eigrp interfaces detail <name> command can be used to verify that the router interface is sending out Multicast packets to discover and maintain neighbour relationships. The output of this command on a router enabled for dynamic neighbour discovery is illustrated below:

R2#show ip eigrp interfaces detail FastEthernet0/0
IP-EIGRP interfaces for process 150
                      Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface      Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0            1        0/0        1        0/1           50           0
  Hello interval is 5 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/2  Un/reliable ucasts: 2/2
  Mcast exceptions: 0  CR packets: 0  ACKs suppressed: 0
  Retransmissions sent: 1  Out-of-sequence rcvd: 0
  Authentication mode is not set
  Use multicast

NOTE: The show ip eigrp neighbors command will be described in detail later. When looking at the output of the show ip eigrp interfaces detail <name> command, keep in mind that because EIGRP uses both Multicast and Unicast packets, the command counters will include values for both types of packets, as shown in the output above.

Static Neighbour Discovery

Unlike the dynamic EIGRP neighbour discovery process, static EIGRP neighbour relationships require manual neighbour configuration on the router. When static EIGRP neighbours are configured, the local router uses the Unicast neighbour address to send packets to these routers.

Static neighbour relationships are seldom used in EIGRP networks. The primary reason for this is the manual configuration of neighbours does not scale well in large networks. However, it is important to understand why this option is available in Cisco IOS software and the situations in which this feature can be utilised. A prime example of when static neighbour configuration could be used would be in a situation where EIGRP is being deployed across media that does not natively support Broadcast or Multicast packets, such as Frame Relay.

A second example would be to prevent sending unnecessary EIGRP packets on Multi-Access networks, such as Ethernet, when only a few EIGRP-enabled routers exist. In addition to basic EIGRP configuration, the neighbor command must be configured on the local router for all static EIGRP neighbours. EIGRP-enabled routers will not establish an adjacency if one router is configured to use Unicast (static) while another uses Multicast (dynamic).

In Cisco IOS software, static EIGRP neighbours are configured using the neighbor <address> <interface> router configuration command. Keep in mind that this is simply in addition to the basic EIGRP configuration. The simple network topology that is illustrated in Figure 36.5 below will be used both to demonstrate and to verify the configuration of static EIGRP neighbours:

Referencing the topology illustrated in Figure 36.5, router R2 is configured as follows:

R2(config)#router eigrp 150
R2(config-router)#network 192.168.1.0 0.0.0.255
R2(config-router)#neighbor 192.168.1.3 FastEthernet0/0
R2(config-router)#no auto-summary
R2(config-router)#exit

The configuration implemented on router R3 is as follows:

R3(config)#router eigrp 150
R3(config-router)#network 192.168.1.0 0.0.0.255
R3(config-router)#neighbor 192.168.1.2 FastEthernet0/0
R3(config-router)#no auto-summary
R3(config-router)#exit

The show ip eigrp interfaces detail <name> command can be used to determine whether the router interface is sending Multicast (dynamic) or Unicast (static) packets for neighbour discovery and maintenance. This is illustrated in the following output:

R2#show ip eigrp interfaces detail FastEthernet0/0
IP-EIGRP interfaces for process 150
                      Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface      Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0            1        0/0        2        0/1           50           0
  Hello interval is 5 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/1  Un/reliable ucasts: 3/8
  Mcast exceptions: 1  CR packets: 1  ACKs suppressed: 2
  Retransmissions sent: 1  Out-of-sequence rcvd: 0
  Authentication mode is not set
  Use unicast

Additionally, the show ip eigrp neighbors [detail] command can be used to determine the type of EIGRP neighbour. This command will be described in detail later in this module.

EIGRP Hello and Hold Timers

Enhanced IGRP uses different Hello and Hold timers for different types of media. Hello timers are used to determine the interval rate EIGRP Hello packets are sent. The Hold timer is used to determine the time that will elapse before a router considers an EIGRP neighbour as down. By default, the Hold time is three times the Hello interval.

Enhanced IGRP sends Hello packets every 5 seconds on Broadcast, Point-to-Point Serial, Pointto- Point subinterfaces, and Multipoint circuits greater than T1 speed. The default Hold time is 15 seconds. EIGRP sends Hello packets every 60 seconds on other link types. These include lowbandwidth WAN links less than T1 speed. The default Hold time for neighbour relationships across these links is also three times the Hello interval and therefore defaults to 180 seconds.

Enhanced IGRP timer values do not have to be the same on neighbouring routers in order for a neighbour relationship to be established. In addition, there is no mandatory requirement that the Hold time be three times the Hello interval. This is only a recommended guideline, which can be manually adjusted in Cisco IOS software. The EIGRP Hello time can be adjusted using the ip hello-interval eigrp <ASN> <secs> interface configuration command, while the EIGRP Hold time can be adjusted using the ip hold-time eigrp <ASN> <secs> interface configuration command.

It is important to understand the use of both Hello timers and Hold timers as they pertain to EIGRP. The Hold time value is advertised in the EIGRP Hello packet, while the Hello time value tells the local router how often to send its neighbour(s) Hello packets. The Hold time, on the other hand, tells the neighbour router(s) of the local router how long to wait before declaring the local router “dead.” The EIGRP Hello packet and the Hold Time field is illustrated in Figure 36.6 below:

Referencing Figure 36.6, the EIGRP Hello packet (OPCode 5) contains, among other things, the configured Hold time value. The value of 15 illustrated in Figure 36.6 is a non-default configured value implemented using the ip hold-time eigrp <ASN> <secs> interface configuration command. It is important to remember that the actual Hello time interval is not included.

However, the configured Hello time can be viewed using the show ip eigrp interfaces detail <name> command. The information printed by this command is illustrated below:

R2#show ip eigrp interfaces detail FastEthernet0/0
IP-EIGRP interfaces for process 150
                      Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface      Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Fa0/0            1       0/0         7        0/1           50           0
  Hello interval is 5 sec
  Next xmit serial <none>
  Un/reliable mcasts: 0/1  Un/reliable ucasts: 2/5
  Mcast exceptions: 1  CR packets: 1  ACKs suppressed: 0
  Retransmissions sent: 1  Out-of-sequence rcvd: 0
  Authentication mode is not set
  Use multicast

The most common reason for adjusting the default EIGRP timer values is to speed up routing protocol convergence. For example, on a low-speed WAN link, a Hold time of 180 seconds might be a long time to wait before EIGRP declares a neighbour router down. Inversely, in some situations, it may be necessary to increase the EIGRP timer values on high-speed links in order to ensure a stable routing topology. This is common when implementing a solution for Stuck-In- Active (SIA) routes. SIA will be described in detail later in this module.

EIGRP Neighbour Table

The EIGRP neighbour table is used by routers running EIGRP to maintain state information about EIGRP neighbours. When newly discovered neighbours are learned, the address and interface of the neighbour is recorded. This is applicable to both dynamically discovered neighbours and statically defined neighbours. There is a single EIGRP neighbour table for each Protocol-Dependent Module (PDM).

When an EIGRP neighbour sends a Hello packet, it advertises a Hold time, which is the amount of time a router treats a neighbour as reachable and operational. After a router receives a Hello packet, the Hold time value begins to decrement and count down to zero. When another Hello packet is received, the Hold time value restarts from the beginning and the process is continually repeated. If a Hello packet is not received within the Hold time, then the Hold time expires (goes to 0). When the Hold time expires, DUAL is informed of the topology change and the neighbour is declared down by EIGRP. A message similar to the following is then printed and logged by the router:

%DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.2 (Serial0/0) is down: holding time expired

The EIGRP neighbour table entry also includes information required by the Reliable Transport Protocol (RTP). RTP is used by EIGRP to ensure that Update, Query, and Reply packets are sent reliably. In addition, sequence numbers are also used to match acknowledgments with data packets. The last sequence number received from the neighbour is recorded in order to detect out-of-order packets. This ensures reliable packet delivery.

NOTE: RTP is described in detail later in this module.

The neighbour table includes a transmission list that is used to queue packets for possible retransmission on a per-neighbour basis. Additionally, round-trip timers are kept in the neighbour data structure to estimate an optimal retransmission interval. All of this information is printed in the output of the show ip eigrp neighbors command, as illustrated below:

R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 150
H   Address      Interface  Hold   Uptime   SRTT   RTO   Q    Seq
                            (sec)           (ms)         Cnt  Num
0   192.168.1.3  Fa0/0      14     00:43:08  2     200   0    12

It is important to understand the information printed by this command, both as a basis for demonstrating competency on a core EIGRP component and for troubleshooting EIGRP issues. Table 36.2 below lists and describes the fields contained in the output of this command:

Table 36.2 – EIGRP Neighbour Table Fields

While the show ip eigrp neighbors command prints out information on known EIGRP neighbours, it does not differentiate between dynamically discovered and manually configured neighbours. For example, the output of the show ip eigrp neighbors command on R2 indicates that the router has two EIGRP neighbour relationships. Based on this configuration, one is a statically configured neighbour, while the other is dynamically discovered. As you can see, it is not possible to determine which is which based on the following output:

R2#show ip eigrp neighbors
IP-EIGRP neighbors for process 150
H   Address       Interface  Hold  Uptime    SRTT   RTO   Q   Seq
                  (sec)          (ms)          Cnt Num
1   150.2.2.2     Se0/0      13    00:00:48  153    918   0   4
0   192.168.1.3   Fa0/0      10    08:33:23  1      200   0   20

In environments where the router has both dynamically discovered and manually configured neighbour relationships, the show ip eigrp neighbors detail command can be used to determine which neighbour is statically configured and which is dynamically discovered, as illustrated below:

R2#show ip eigrp neighbors detail
IP-EIGRP neighbors for process 150
H   Address      Interface   Hold  Uptime    SRTT   RTO   Q     Seq
                 (sec)            (ms)         Cnt   Num
1   150.2.2.2    Se0/0       11    00:04:22  153    918   0     4
   Version 12.3/1.2, Retrans: 0, Retries: 0, Prefixes: 1
0   192.168.1.3  Fa0/0       10    08:36:58  1      200   0     20
   Static neighbor
   Version 12.4/1.2, Retrans: 0, Retries: 0, Prefixes: 1

Referencing the output above, neighbour 192.168.1.3 is a manually configured neighbour and neighbour 150.2.2.2 is a dynamically discovered neighbour. The static neighbours can also be viewed using the show ip eigrp neighbors static <interface> command, as illustrated below:

R2#show ip eigrp neighbors static FastEthernet0/0
IP-EIGRP neighbors for process 150
Static Address          Interface
192.168.1.3             FastEthernet0/0

Reliable Transport Protocol

Enhanced IGRP needs its own transport protocol to ensure the reliable delivery of packets. RTP is used by EIGRP to ensure that Update, Query, and Reply packets are sent reliably. The use of sequence numbers also ensures that the EIGRP packets are received in the correct order.

When reliable EIGRP packets are sent to a neighbour, the sending router expects an ACK from the receiving routers stating that the packet has been received. Using RTP, EIGRP maintains a transport window of one unacknowledged packet, which means that every single reliable packet that is sent out must be acknowledged before the next reliable packet can be sent. The sending router will retransmit the unacknowledged reliable packet until it receives an ACK.

It is important to note, however, that the unacknowledged packet will be retransmitted only up to 16 times. If there is still no acknowledgment after 16 retransmissions, EIGRP will reset the neighbour relationship. RTP uses both Multicast and Unicast packets. On Broadcast Multi- Access networks such as Ethernet, EIGRP uses Multicast packets instead of sending an individual packet (Unicast) to each router on the segment. However, packets may also be sent using Unicast if a response is not received from one or more of the neighbours on the Multi- Access segment. This is described referencing the diagram in Figure 36.7 below:

In Figure 36.7, routers R1, R2, and R3 reside on a common subnet on the Multi-Access segment. Given the media, EIGRP will use Multicast to send reliable packets between the routers. Assume, for example, that R1 sends out a packet that requires acknowledgment to routers R2 and R3. R1 then waits for acknowledgement from R2 and R3 confirming receipt of this packet.

Assume that R3 responds but R2 is unable to respond to this packet. Given that EIGRP maintains a transport window of one unacknowledged packet, which means that every individual reliable packet that is sent out must be acknowledged explicitly by the neighbour router(s) before the next reliable packet can be sent, this presents a possible issue on the Multi-Access segment because R1 will not be able to send out packets until it has received the acknowledgment from R2. R3 is therefore indirectly affected by the issues on R2.

To avoid this potential pitfall, R1 will wait for the Multicast Flow Timer (MFT) on the Ethernet interface connected to the Multi-Access segment to expire. The MFT, or simply the Flow Timer, is the maximum amount of time that the sending router will wait for an ACK packet from a group member. When the timer expires, R1 will Multicast a special EIGRP packet called a Sequence TLV. This packet lists R2 (the offender) and indicates an out-of-sequence Multicast packet. Because R3 is not listed in this packet, it enters Conditional Receive (CR) mode and continues listening to Multicast packets. R1 uses Unicast to retransmit the packet to R2. The Retransmission Timeout (RTO) indicates the time that the router waits for an acknowledgement of that Unicast packet. If after 16 total attempts there is still no response from R2, then EIGRP will reset the neighbour.

NOTE: You are not required to go into any detail on MFT or RTO in the current CCNA exam.

Metrics, DUAL, and the Topology Table

When implementing EIGRP, it is important to understand the various aspects used within and by the protocol before routes are actually placed into the IP routing table. In this section, you will learn about the EIGRP composite metric and how it is calculated. You will also learn about the different ways to influence metric calculation, as well as to adjust the calculated metric.

Following that, you will learn about the Diffusing Update Algorithm (DUAL) and the EIGRP topology table. This section concludes with a discussion on how all this information meshes when it comes to populating the IP routing table on a router running EIGRP.

EIGRP Composite Metric Calculation

Enhanced IGRP uses a composite metric, which includes different variables referred to as the K values. The K values are constants that are used to distribute weight to different path aspects, which may be included in the composite EIGRP metric. The default values for the K values are K1 = K3 = 1 and K2 = K4 = K5 = 0. In other words, K1 and K3 are set to a default value of 1, while K2, K4, and K5 are set to a default value of 0.

Assuming the default K value settings, the complete EIGRP metric can be calculated using the following mathematical formula:

[K1 * bandwidth + (K2 * bandwidth) / (256 - load) + K3 * delay] * [K5 / (reliability + K4)]

However, given that only K1 and K3 have any positive values by default, the default EIGRP metric calculation is performed using the following mathematical formula:

[(10⁷ ⁄ least bandwidth on path) + (sum of all delays)] × 256

This essentially means that, by default, EIGRP uses the minimum bandwidth on the path to a destination network and the total cumulative delay to compute routing metrics. However, Cisco IOS software allows administrators to set other K values to non-zero values to incorporate other variables into the composite metric. This may be performed using the metric weights [tos] k1 k2 k3 k4 k5 router configuration command.

When using the metric weights command, [tos] stands for Type of Service. Although Cisco IOS software shows that any value between 0 and 8 may be used, as of the time this guide was written, this field can currently be set only to zero. The K values can be set to any value between 0 and 255. The default EIGRP K values can be viewed by issuing the show ip protocols command. This is illustrated in the following output:

R2#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    192.168.1.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    192.168.1.3           90      00:00:15
  Distance: internal 90 external 170

When adjusting the EIGRP K values, it is important to remember that the same values must be configured on all routers within the EIGRP domain. If the K values are mismatched, EIGRP neighbour relationships will not be established.

NOTE: Adjusting the default K value settings is not recommended. It should be done only with the assistance of seasoned senior-level engineers who have a solid understanding of the implications of such actions within the network or based upon the recommendation of the Cisco Technical Assistance Centre (TAC).

Using Interface Bandwidth to Influence EIGRP Metric Calculation

Enhanced IGRP metric calculation can be directly influenced by adjusting the default bandwidth values assigned to individual interfaces using the bandwidth command. The bandwidth values specified by this command are in Kilobits. The bandwidth used in EIGRP metric calculation is also in Kilobits. Figure 36.8 below illustrates a network comprised of two routers connected via two Serial (T1) links that have a bandwidth value of 1544Kbps:

Referencing the diagram in Figure 36.8, because of the equal bandwidth (and delay) values of the links between R1 and R2, the same EIGRP metric will be derived for both paths from R2 to the 172.16.100.0/24 subnet. EIGRP will load-share traffic between the two Serial links, as illustrated in the following output on R2:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 2172416, type internal
  Redistributing via eigrp 150
  Last update from 150.2.2.1 on Serial0/1, 00:48:09 ago
  Routing Descriptor Blocks:
    150.2.2.1, from 150.2.2.1, 00:48:09 ago, via Serial0/1
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 150.1.1.1, from 150.1.1.1, 00:48:09 ago, via Serial0/0
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

Adjusting the default bandwidth value on either interface will directly influence the EIGRP metric calculation for the path to the destination network. Such actions can be used for path control within larger networks (i.e., controlling the path that traffic takes based on administrator-defined values and configurations). For example, if it was preferred that EIGRP use Serial0/0 as the primary path to the destination network and Serial0/1 as the backup path to the destination, one of two actions could be taken.

The first is that the bandwidth value on Serial0/0 could be incremented, resulting in a better (lower) metric for this path. The second is that the bandwidth value on Serial0/1 could be decremented, resulting in a worse (higher) metric for this path. Either option is acceptable and will achieve the desired result. The following output illustrates how to decrement the default bandwidth value on Serial0/1, effectively ensuring that Serial0/0 is used as the primary path between R2 and the 172.16.100.0/24 network:

R2(config)#interface Serial0/1
R2(config-if)#bandwidth 1024
R2(config-if)#exit

NOTE: As stated in Day 1, this configuration does not mean that Serial0/1 is now capable of only 1024Kbps of throughput through this interface.

The result of this configuration is that Serial0/0 is the primary path used by R2 to get to the 172.16.100.0/24 destination network. This is illustrated in the following output:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 2172416, type internal
  Redistributing via eigrp 150
  Last update from 150.1.1.1 on Serial0/0, 00:01:55 ago
  Routing Descriptor Blocks:
  * 150.1.1.1, from 150.1.1.1, 00:01:55 ago, via Serial0/0
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

NOTE: The asterisk (*) points to the interface over which the next packet is sent. In the event that there are multiple equalcost routes in the routing table, the position of the * rotates among the equal-cost paths.

Although the path via the Serial0/1 interface is not installed into the routing table, when using EIGRP as the routing protocol, it is important to remember that this path is not completely ignored. Instead, this path is stored in the EIGRP topology table, which contains the primary and alternate (backup) paths to remote destination networks. The EIGRP topology table will be described in detail later in this module.

NOTE: By default, when EIGRP is enabled, it can use up to 50% of the interface bandwidth to send EIGRP packets (EIGRP is a very chatty protocol, so it limits itself in possible bandwidth usage). EIGRP determines the bandwidth amount based on the bandwidth interface configuration command. Therefore, when adjusting interface bandwidth values, it is important to keep this fact in mind. This default setting can be adjusted by using the ip bandwidth-percent eigrp [ASN] [percentage] interface configuration command.

In summation, when using the bandwidth command to influence EIGRP metric calculation, it is important to remember that EIGRP uses the minimum bandwidth on the path to a destination network, along with the cumulative delay, to compute routing metrics. It is important to have a solid understanding of the network topology to best determine where to use the bandwidth command to influence EIGRP metric calculation. In the real world, however, delay is the preferred method of influencing EIGRP metrics.

Using Interface Delay to Influence EIGRP Metric Calculation

The interface delay value is presented in microseconds. The delay value used in EIGRP metric calculation is in tens of microseconds. Therefore, the delay value on the interface must be divided by 10 in order to compute the EIGRP metric. Table 36.3 below shows the default interface bandwidth and delay values used in Cisco IOS software:

Table 36.3 – Default Interface Bandwidth and Delay Values

When working with the interface bandwidth and delay values, it is very important to remember that adjusting the interface bandwidth value does not automatically adjust the interface delay value, and vice-versa. The two values are independent of each other. As an example, the output that follows shows the default bandwidth and delay values for a FastEthernet interface:

R2#show interfaces FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
  Hardware is AmdFE, address is 0013.1986.0a20 (bia 0013.1986.0a20)
  Internet address is 192.168.1.2/24
  MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255
...
[Truncated Output]

To reinforce this concept, the bandwidth value on the FastEthernet interface is adjusted to 1544Kbps using the bandwidth interface configuration command, as follows:

R2(config)#interface FastEthernet0/0
R2(config-if)#bandwidth 1544
R2(config-if)#exit

While the bandwidth value now displayed in the output of the show interfaces command reflects the implemented configuration, the default interface delay value remains the same, as illustrated below:

R2#show interfaces FastEthernet0/0
FastEthernet0/0 is up, line protocol is up
  Hardware is AmdFE, address is 0013.1986.0a20 (bia 0013.1986.0a20)
  Internet address is 192.168.1.2/24
  MTU 1500 bytes, BW 1544 Kbit/sec, DLY 100 usec,
     reliability 255/255, txload 1/255, rxload 1/255

The cumulative delay used by EIGRP is the sum of all interface delays between the source and the destination network. Changing any of the delay values in the path influences EIGRP metric calculation. The interface delay value is adjusted using the delay interface configuration command. This value is then divided by 10 when used in EIGRP metric calculation. Figure 36.9 below illustrates a network comprised of two routers connected via two Serial (T1) links that have a bandwidth value of 1544Kbps and a default delay of 20000 microseconds. In addition, the 172.16.100.0/24 network is directly connected to a FastEthernet interface, which has a default bandwidth of 100000Kbps and a default delay value of 100 microseconds:

The EIGRP metric from R2 to the 172.16.100.0/24 network is calculated as follows:

Metric = [(10⁷ ⁄ least bandwidth on path) + (sum of all delays)] × 256
Metric = [(10000000 ⁄ 1544) + (2000 + 10)] × 256

NOTE: Remember to divide the interface delay values by 10 for EIGRP metric calculation.

Metric = [(10000000 ⁄ 1544) + (2000 + 10)] × 256

NOTE: The calculated value should always be rounded down to the nearest integer.'

Metric = [6476 + 2010] × 256
Metric = 8486 × 256
Metric = 2172416

This calculation can be verified by the show ip route command, as follows:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 2172416, type internal
  Redistributing via eigrp 150
  Last update from 150.2.2.1 on Serial0/1, 00:03:28 ago
  Routing Descriptor Blocks:
    150.2.2.1, from 150.2.2.1, 00:03:28 ago, via Serial0/1
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 150.1.1.1, from 150.1.1.1, 00:03:28 ago, via Serial0/0
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

As with the bandwidth command, you can either increment or decrement the interface delay value using the delay command to influence EIGRP metric calculation. For example, to configure R2 to use the Serial0/0 link to get to the 172.16.100.0/24 network, with Serial0/1 being used as a backup link only, the delay value on Serial0/0 could be decremented as follows:

R2(config)#int s0/0
R2(config-if)#delay 100
R2(config-if)#exit

This configuration adjusts the EIGRP metric for the path via Serial0/0, as illustrated below:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 1686016, type internal
  Redistributing via eigrp 150
  Last update from 150.1.1.1 on Serial0/0, 00:01:09 ago
  Routing Descriptor Blocks:
  * 150.1.1.1, from 150.1.1.1, 00:01:09 ago, via Serial0/0
      Route metric is 1686016, traffic share count is 1
      Total delay is 1100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

The path via Serial0/1 is retained in the topology table as an alternate path to the network.

The Diffusing Update Algorithm (DUAL)

The Diffusing Update Algorithm is at the crux of the EIGRP routing protocol. DUAL looks at all routes received from neighbour routers, compares them, and then selects the lowest metric (best) loop-free path to the destination network, which is the Feasible Distance (FD), resulting in the Successor route. The FD includes both the metric of a network as advertised by the connected neighbour plus the cost of reaching that particular neighbour.

The metric that is advertised by the neighbour router is referred to as the Reported Distance (RD) or as the Advertised Distance (AD) to the destination network. Therefore, the FD includes the RD plus the cost of reaching that particular neighbour. The next-hop router for the Successor route is referred to as the Successor. The Successor route is placed into the IP routing table and the EIGRP topology table and points to the Successor.

Any other routes to the same destination network that have a lower RD than the FD of the Successor path are guaranteed to be loop-free and are referred to as Feasible Successor (FS) routes. These routes are not placed into the IP routing table; however, they are still placed into the EIGRP topology table, along with the Successor routes.

In order for a route to become an FS route, it must meet the Feasibility Condition (FC), which occurs only when the RD to the destination network is less than the FD. In the event that the RD is more than the FD, the route is not selected as an FS. This is used by EIGRP to prevent the possibility of loops. The network topology illustrated in Figure 36.10 below will be used to clarify the terminology referred to in this section:

Referencing Figure 36.10, Table 36.4 below shows the Feasible Distance and the Reported Distance values as seen on R1 for the 192.168.100.0/24 network:

Table 36.4 – R1 Paths and Distances

Based on the information in Table 36.4, R1 will select the path through R4 as the Successor route based on the FD for the route, which is 25. This route will be placed into the IP routing table as well as the EIGRP topology table. R1 then looks at alternate paths to the 192.168.100.0/24 network. The metric for neighbour R3 to the 192.168.100.0/24 network, also referred to as the RD or AD, is 10. This is less than the FD and so this route meets the FC and is placed into the EIGRP topology table. The metric for neighbour R2 to the 192.168.100.0/24 network is 30. This value is higher than the FD of 25. This route does not meet the FC and is not considered an FS. The route, however, is still placed into the EIGRP topology table. This is illustrated in the section on the EIGRP topology table that follows.

When a neighbour changes a metric, or when a topology change occurs, and the Successor route is removed or changes, DUAL checks for FSs for the route and if one is found, then DUAL uses it to avoid re-computing the route unnecessarily. This is referred to as local computation. Performing a local computation saves CPU power because the FS has been chosen and already exists before the Successor or primary route fails.

When no FS for the destination network exists, the local router will send a Query to neighbouring routers asking if they have information on the destination network. If the information is available and another neighbour does have a route to the destination network, then the router performs a diffusing computation to determine a new Successor.

The EIGRP Topology Table

The EIGRP topology table is populated by EIGRP PDMs acted upon by the DUAL Finite State Machine. All known destination networks and subnets that are advertised by neighbouring EIGRP routers are stored in the EIGRP topology table. This includes Successor routes, FS routes, and even routes that have not met the FC.

The topology table allows all EIGRP routers to have a consistent view of the entire network. It also allows for rapid convergence in EIGRP networks. Each individual entry in the topology table contains the destination network and the neighbour(s) that have advertised the destination network. Both the FD and the RD are stored in the topology table. The EIGRP topology table contains the information needed to build a set of distances and vectors to each reachable network, including the following:

• The lowest bandwidth on the path to the destination network
• The total or cumulative delay to the destination network
• The reliability of the path to the destination network
• The loading of the path to the destination network
• The minimum Maximum Transmission Unit (MTU) to the destination network
• The Feasible Distance to the destination network
• The Reported Distance by the neighbour router to the destination network
• The route source (only external routes) of the destination network

NOTE: While the MTU is included in the topology table, EIGRP does not use this value in actual metric computation. Instead, the MTU is simply tracked to determine the minimum value to the destination network. The interface MTU specifies the largest size of datagram that can be transferred across a certain link without the need for fragmentation, or breaking the datagram or packet into smaller pieces.

The contents of the EIGRP topology table are viewed using the show ip eigrp topology command. The options that are available with this command are illustrated below:

R2#show ip eigrp topology ?
<1-65535>       AS Number
A.B.C.D         IP prefix <network>/<length>, e.g., 192.168.0.0/16
A.B.C.D         Network to display information about
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
<cr>

The show ip eigrp topology command with no options prints only the Successor and Feasible Successor information for routes in the topology table and for all of the EIGRP instances enabled on the router. The output printed by this command is illustrated below:

R2#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(2.2.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 150.2.2.0/24, 1 successors, FD is 20512000
        via Connected, Serial0/1
        via 150.1.1.1 (2195456/2169856), Serial0/0
P 150.1.1.0/24, 1 successors, FD is 1683456
        via Connected, Serial0/0
P 172.16.100.0/24, 1 successors, FD is 1686016
        via 150.1.1.1 (1686016/28160), Serial0/0

The show ip eigrp topology [network]/[prefix] and show ip eigrp topology [network] [mask] commands print Successor routes, FS routes, and routes that have not met the FC for the route specified in either command. The following illustrates the use of the show ip eigrp topology [network]/[prefix]command:

R2#show ip eigrp topology 172.16.100.0/24
IP-EIGRP (AS 150): Topology entry for 172.16.100.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 1686016
  Routing Descriptor Blocks:
  150.1.1.1 (Serial0/0), from 150.1.1.1, Send flag is 0x0
      Composite metric is (1686016/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 1100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  150.2.2.1 (Serial0/1), from 150.2.2.1, Send flag is 0x0
      Composite metric is (2167998207/2147511807), Route is Internal
      Vector metric:
        Minimum bandwidth is 128 Kbit
        Total delay is 83906179 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

In the output above, you can see that the path via Serial0/1 does not meet the FC because the RD exceeds the FD. This is why the path is not printed in the output of the show ip eigrp topology command. Instead of viewing each prefix on an individual basis to determine Successor routes, FS routes, and routes that did not meet the FC, you can use the show ip eigrp topology all-links command to view all possible routes for all of the prefixes in the EIGRP topology table. The output of this command is illustrated below:

R2#show ip eigrp topology all-links
IP-EIGRP Topology Table for AS(150)/ID(2.2.2.2)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 150.2.2.0/24, 1 successors, FD is 20512000, serno 42
        via Connected, Serial0/1
        via 150.1.1.1 (2195456/2169856), Serial0/0
P 150.1.1.0/24, 1 successors, FD is 1683456, serno 32
        via Connected, Serial0/0
        via 150.2.2.1 (21024000/2169856), Serial0/1
P 172.16.100.0/24, 1 successors, FD is 1686016, serno 47
        via 150.1.1.1 (1686016/28160), Serial0/0
        via 150.2.2.1 (2167998207/2147511807), Serial0/1

Within the EIGRP topology table, entries may be marked either as Passive (P) or as Active (A). A route in the Passive state indicates that EIGRP has completed actively computing the metric for the route and traffic can be forwarded to the destination network using the Successor route. This is the preferred state for all routes in the topology table.

Enhanced IGRP routes are in an Active state when the Successor route has been lost and the router sends out a Query packet to determine an FS. Usually, an FS is present and EIGRP promotes that to the Successor route. This way, the router converges without involving other routers in the network. This process is referred to as a local computation.

However, if the Successor route has been lost or removed, and there is no FS, then the router will begin diffused computation. In diffused computation, EIGRP will send a Query out to all neighbours and out of all interfaces, except for the interface to the Successor route. When an EIGRP neighbour receives a Query for a route, and if that neighbour’s EIGRP topology table does not contain an entry for the route, then the neighbour immediately replies to the Query with an unreachable message, stating that there is no path for this route through this neighbour.

If the EIGRP topology table on the neighbour lists the router sending the Query as the Successor for that route, and an FS exists, then the FS is installed and the router replies to the neighbour Query that it has a route to the lost destination network.

However, if the EIGRP topology table lists the router sending the Query as the Successor for this route and there is no FS, then the router queries all of its EIGRP neighbours, except those that were sent out of the same interface as its former Successor. The router will not reply to the Query until it has received a Reply to all Queries that it originated for this route.

Finally, if the Query was received from a neighbour that is not the Successor for this destination, then the router replies with its own Successor information. If the neighbouring routers do not have the lost route information, then Queries are sent from those neighbouring routers to their neighbouring routers until the Query boundary is reached. The Query boundary is either the end of the network, the distribute list boundary, or the summarisation boundary.

Once the Query has been sent, the EIGRP router must wait for all replies to be received before it calculates the Successor route. If any neighbour has not replied within three minutes, the route is said to be Stuck-in-Active (SIA). When a route is SIA, the neighbour relationship of the router(s) that did not respond to the Query will be reset. In such cases, you will see a message logged by the router similar to the following:

%DUAL-5-NBRCHANGE: IP-EIGRP 150:
    Neighbor 150.1.1.1(Serial0/0) is down: stuck in active
%DUAL-3-SIA:
    Route 172.16.100.0/24 stuck-in-active state in IP-EIGRP 150.
Cleaning up

There are several reasons why the EIGRP neighbour router(s) may not respond to the Query, which include the following:

• The neighbour router’s CPU is overloaded and it cannot respond in time
• The neighbour router itself has no information about the lost route
• Quality issues on the circuit are causing packets to be lost
• Low-bandwidth links are congested and packets are being delayed

To prevent SIA issues due to delayed responses from other EIGRP neighbours, the local router can be configured to wait for longer than the default of three minutes to receive responses back to its Query packets using the timers active-time command in Router Configuration mode.

NOTE: It is important to note that if you change this default parameter on one EIGRP router in your network, you must change it on all the other routers within your EIGRP routing domain.

Equal Cost and Unequal Cost Load Sharing

Cisco IOS software supports equal cost load sharing for a default of up to four paths for all routing protocols. This is illustrated below in the output of the show ip protocols command:

R2#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    150.1.1.2/32
    150.2.2.2/32
  Routing Information Sources:
    Gateway         Distance      Last Update
    Gateway         Distance      Last Update
    150.2.2.1             90      00:00:52
    150.1.1.1             90      00:00:52
  Distance: internal 90 external 170

The maximum-paths <1-6> router configuration command can be used to change the default value of four maximum paths up to a maximum of six equal cost paths. When performing equal cost load balancing, the router distributes the load evenly among all paths. The traffic share count identifies the number of outgoing packets on each path. When performing equal cost load balancing, one packet is sent on each individual path, as illustrated in the following output:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 2172416, type internal
  Redistributing via eigrp 150
  Last update from 150.2.2.1 on Serial0/1, 00:04:00 ago
  Routing Descriptor Blocks:
    150.2.2.1, from 150.2.2.1, 00:04:00 ago, via Serial0/1
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 150.1.1.1, from 150.1.1.1, 00:04:00 ago, via Serial0/0
      Route metric is 2172416, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

In addition to equal cost load balancing capabilities, EIGRP is also able to perform unequal cost load sharing. This unique ability allows EIGRP to use unequal cost paths to send outgoing packets to the destination network based on weighted traffic share values. Unequal cost load sharing is enabled using the variance <multiplier> router configuration command.

The <multiplier> keyword is an integer between 1 and 128. A multiplier of 1, which is the default, implies that no unequal cost load sharing is being performed. This default setting is illustrated below in the output of the show ip protocols command:

R2#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    150.1.1.2/32
    150.2.2.2/32
  Routing Information Sources:
    Gateway         Distance      Last Update
    150.2.2.1             90      00:00:52
    150.1.1.1             90      00:00:52
  Distance: internal 90 external 170

The multiplier is a variable integer that tells the router to load share across routes that have a metric that is less than the minimum metric multiplied by the multiplier. For example, specifying a variance of 5 instructs the router to load share across routes whose metric is less than 5 times the minimum metric. The default variance of 1 tells the router to perform equal cost load balancing. When the variance command is used and a value other than 1 is specified as the multiplier, the router will distribute traffic among the routes proportionately, with respect to the metric of each individual route. In other words, the router will send more traffic using those paths with lower metric values than those with higher metric values.

Figure 36.11 below illustrates a basic network running EIGRP. R1 and R2 are connected via backto- back Serial links. The 150.1.1.0/24 link between the two routers has a bandwidth of 1024Kbps. The 150.2.2.0/24 link between the routers has a bandwidth of 768Kbps. R1 is advertising the 172.16.100.0/24 prefix via EIGRP to R2:

Based on the topology illustrated in Figure 36.11, the routing table on R2 for the 172.16.100.0/24 prefix is shown in the following output:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 3014400, type internal
  Redistributing via eigrp 150
  Last update from 150.1.1.1 on Serial0/0, 00:00:11 ago
  Routing Descriptor Blocks:
  * 150.1.1.1, from 150.1.1.1, 00:00:11 ago, via Serial0/0
      Route metric is 3014400, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1024 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

The following EIGRP topology table shows both the Successor and the Feasible Successor routes:

R2#show ip eigrp topology 172.16.100.0 255.255.255.0
IP-EIGRP (AS 150): Topology entry for 172.16.100.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 3014400
  Routing Descriptor Blocks:
  150.1.1.1 (Serial0/0), from 150.1.1.1, Send flag is 0x0
      Composite metric is (3014400/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 1024 Kbit
        Total delay is 20100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
  150.2.2.1 (Serial0/1), from 150.2.2.1, Send flag is 0x0
      Composite metric is (3847680/28160), Route is Internal
      Vector metric:
        Minimum bandwidth is 768 Kbit
        Total delay is 20100 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

To determine the variance value to configure on the router, you can use the following formula:

Variance = Highest metric for the paths being considered / Metric for the best route

Using this formula, you can calculate the variance value to configure on R2 as follows:

Variance = Highest metric for the paths being considered / Metric for the best route
Variance = 3847680 / 3014400
Variance = 1.28

This value must then be rounded up to the nearest whole integer, which in this case is 2. Given this, R2 can be configured to perform unequal cost load sharing by implementing the following configuration in Router Configuration mode:

R2(config)#router eigrp 150
R2(config-router)#variance 2
R2(config-router)#exit

Following this configuration, the routing table entry for 172.16.100.0/24 is illustrated below:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 3014400, type internal
  Redistributing via eigrp 150
  Last update from 150.2.2.1 on Serial0/1, 00:00:36 ago
  Routing Descriptor Blocks:
    150.2.2.1, from 150.2.2.1, 00:00:36 ago, via Serial0/1
      Route metric is 3847680, traffic share count is 47
      Total delay is 20100 microseconds, minimum bandwidth is 768 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 150.1.1.1, from 150.1.1.1, 00:00:36 ago, via Serial0/0
      Route metric is 3014400, traffic share count is 60
      Total delay is 20100 microseconds, minimum bandwidth is 1024 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

The traffic share count indicates that for every 60 packets forwarded via Serial0/0, the router will forward 47 packets via Serial0/1. This is performed proportionally in respect to the route metric of either path. This is the default behaviour when the variance command is implemented. This intelligent traffic sharing functionality is enabled via the traffic-share balanced router configuration command, which requires no explicit configuration.

NOTE: The traffic-share balanced command is enabled by default and does not appear in the running configuration, even if manually configured. This is illustrated below:

R2(config)#router eigrp 150
R2(config-router)#vari 2
R2(config-router)#traffic-share balanced
R2(config-router)#exit
R2(config)#do show run | begin router
router eigrp 150
variance 2
network 150.1.1.2 0.0.0.0
network 150.2.2.2 0.0.0.0
no auto-summary
As stated previously in this section, when the variance command is used, all paths that both meet the Feasibility Condition and have a metric that is less than the minimum metric multiplied by the multiplier will be installed into the routing table. The router will then use all paths and load share traffic proportionally based on the route metric.

In some cases, you may want to allow alternate routes, such as the Feasible Successor route, to be placed into the routing table but not be used unless the Successor route is removed. Such actions are typically performed to reduce convergence times in EIGRP-enabled networks. To understand this concept, recall that, by default, the router only places the Successor route into the IP routing table. In the event that the Successor route is no longer available, the Feasible Successor route is promoted to the Successor route. This route is then installed into the routing table as the primary path to the destination network.

The traffic-share min across-interfaces router configuration command can be used in conjunction with the variance command to install all routes that have a metric less than the minimum metric multiplied by the multiplier into the routing table, but use only the route with the minimum (best) metric to forward packets until that route becomes unavailable. The primary objective of this configuration is that in the event that the primary route is lost, the alternative route is already in the routing table and can be used immediately.

The following configuration example uses the topology shown in Figure 36.11 above to illustrate how to configure the router to place routes with a metric less than two times the minimum metric into the routing table, but use only the route with the lowest metric to actually forward packets:

R2(config)#router eigrp 150
R2(config-router)#vari 2
R2(config-router)#traffic-share min across-interfaces
R2(config-router)#exit

This configuration results in the following output for 172.16.100.0/24 in the routing table:

R2#show ip route 172.16.100.0 255.255.255.0
Routing entry for 172.16.100.0/24
  Known via “eigrp 150”, distance 90, metric 3014400, type internal
  Redistributing via eigrp 150
  Last update from 150.2.2.1 on Serial0/1, 00:09:01 ago
  Routing Descriptor Blocks:
    150.2.2.1, from 150.2.2.1, 00:09:01 ago, via Serial0/1
      Route metric is 3847680, traffic share count is 0
      Total delay is 20100 microseconds, minimum bandwidth is 768 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1
  * 150.1.1.1, from 150.1.1.1, 00:09:01 ago, via Serial0/0
      Route metric is 3014400, traffic share count is 1
      Total delay is 20100 microseconds, minimum bandwidth is 1024 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

As is illustrated in the output above, the two different metric routes have been installed into the routing table based on the variance configuration. However, notice the traffic share count for the route via Serial0/1 is 0 while the traffic share count for the route via Serial0/0 is 1. This means that the router will not send any packets to 172.16.100.0/24 via Serial0/1, even though the route entry is installed into the routing table, until the path via Serial0/0 is no longer available.

Default Routing Using EIGRP

Enhanced IGRP supports numerous ways to advertise dynamically the gateway or network of last resort to other routers within the routing domain. A gateway of last resort, or default route, is a method for the router to direct traffic when the destination network is not specifically listed in the routing table. These methods are as follows:

• Using the ip default-network command
• Using the network command to advertise network 0.0.0.0/0
• Redistributing the default static route
• Using the ip summary-address eigrp [asn] [network] [mask] command

The use of the ip default-network command is considered a legacy method of advertising the default route dynamically using EIGRP. However, because it is still supported in current IOS software versions, it is worth mentioning.

The ip default-network configuration command flags a network as the default network by inserting an asterisk (*) next to the network in the routing table. Traffic for destinations to which there is no specific routing table entry is then forwarded by the router to this network. The implementation of this feature is illustrated referencing the EIGRP topology in Figure 36.12 below:

Referencing Figure 36.12, assume that the 200.10.10.0/24 subnet is connected to the Internet. This subnet resides off the FastEthernet0/0 interface of R1. R1 and R2 are in turn connected via a back-to-back Serial connection. Both routers reside in EIGRP AS 150. To flag the 200.10.10.0/24 network as the network of last resort, the following configuration is implemented on R1:

R1(config)#router eigrp 150
R1(config-router)#network 200.10.10.0 0.0.0.255
R1(config-router)#exit
R1(config)#ip default-network 200.10.10.0
R1(config)#exit

Based on this configuration, R2 receives 200.10.10.0/24 as the network of last resort, as follows:

R2#show ip route
Codes: 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
Gateway of last resort is 150.2.2.1 to network 200.10.10.0
D*   200.10.10.0/24 [90/2172416] via 150.2.2.1, 00:01:03, Serial0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Serial0/0

The network command can be used to advertise an existing static default route point to either a physical or a logical interface, typically the Null0 interface.

NOTE: The Null0 interface is a virtual interface on the router that discards all traffic that is routed to it. If you have a static route pointing to Null0, all traffic destined for the network specified in the static route is simply discarded. Think of the Null0 interface as a black hole: packets enter, but none ever leaves. It is essentially a bit-bucket on the router.

Referencing the diagram in Figure 36.12 above, the use of the network command in conjunction with an existing default static route is illustrated in the following configuration on R1:

R1(config)#ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
R1(config)#router eigrp 150
R1(config-router)#network 0.0.0.0
R1(config-router)#exit

Based on this configuration, the IP routing table on R2 is illustrated in the following output:

R2#show ip route
Codes: 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
Gateway of last resort is 150.1.1.1 to network 0.0.0.0
D    200.10.10.0/24 [90/2172416] via 150.1.1.1, 00:01:11, Serial0/0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Serial0/0
D*   0.0.0.0/0 [90/2172416] via 150.1.1.1, 00:00:43, Serial0/0

Although route redistribution isn’t part of the CCNA exam, it will be outlined here. This is the third method of advertising a default route via EIGRP. To redistribute the existing static default route into EIGRP, use the redistribute static metric [bandwidth] [delay] [reliability] [load] [MTU] router configuration command. The same network topology used for the previous outputs in this section will be used to illustrate the implementation of this method, as illustrated in Figure 36.13 below:

Referencing Figure 36.13, which is the same as Figure 36.12, the following is performed on R1:

R1(config)#ip route 0.0.0.0 0.0.0.0 FastEthernet0/0
R1(config)#router eigrp 150
R1(config-router)#redistribute static metric 100000 100 255 1 1500
R1(config-router)#exit

NOTE: The values used in the metric can be derived from the interface, or you can specify any values that you want when using this command.

Based on this configuration, the routing table on R2 is illustrated below:

R2#show ip route
Codes: 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
Gateway of last resort is 150.1.1.1 to network 0.0.0.0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Serial0/0
D*EX 0.0.0.0/0 [170/2195456] via 150.1.1.1, 00:01:16, Serial0/0

Because the route was redistributed into EIGRP on R1, it is an external EIGRP route, as reflected in the output above. For external routes, the EIGRP topology table includes information such as the router that originated the route, the protocol the route was received for, and the metric of the external route, for example. This is illustrated in the following output:

R2#show ip eigrp topology 0.0.0.0/0
IP-EIGRP (AS 150): Topology entry for 0.0.0.0/0
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2195456
  Routing Descriptor Blocks:
  150.1.1.1 (Serial0/0), from 150.1.1.1, Send flag is 0x0
      Composite metric is (2195456/51200), Route is External
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 21000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 1.1.1.1
        AS number of route is 0
        External protocol is Static, external metric is 0
        Administrator tag is 0 (0x00000000)
        Exterior flag is set

From the information in bold, you can see that the default route is a static route that was redistributed into EIGRP on R1. This route has a metric of 0. In addition, you can also see that the EIGRP router ID (RID) of R1 is 1.1.1.1.

The final method of advertising the default route is by using the ip summary-address eigrp [asn] [network] [mask] interface configuration command. EIGRP route summarisation will be described in detail later in this module. For the moment, concentrate on the use of this command to advertise the default route when using EIGRP.

Referencing the network topology diagram illustrated in Figure 36.13 above, R1 is configured with the ip summary-address eigrp [asn] [network] [mask] interface configuration command to advertise the default route to R2, as follows:

R1(config)#interface Serial0/0
R1(config-if)#description ‘Back-to-Back Serial Connection To R2 Serial0/0’
R1(config-if)#ip summary-address eigrp 150 0.0.0.0 0.0.0.0
R1(config-if)#exit

The primary advantage to using this command is that a default route or network does not need to exist in the routing table in order for EIGRP to advertise network 0.0.0.0/0 to its neighbour routers. When this command is issued, the local router generates a summary route to the Null0 interface and flags the entry as the candidate default route. This is illustrated below:

R1#show ip route
Codes: 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
Gateway of last resort is 0.0.0.0 to network 0.0.0.0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Serial0/0
D*   0.0.0.0/0 is a summary, 00:02:26, Null0

The summary route is received as an internal EIGRP route on R2, as illustrated below:

R2#show ip route
Codes: 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
Gateway of last resort is 150.1.1.1 to network 0.0.0.0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Serial0/0
D*   0.0.0.0/0 [90/2297856] via 150.1.1.1, 00:03:07, Serial0/0

Split Horizon in EIGRP Networks

Previously, you learned that split horizon is a Distance Vector protocol feature mandating that routing information cannot be sent back out of the same interface through which it was received. This prevents the re-advertising of information back to the source from which it was learned. While this characteristic is a great loop prevention mechanism, it is also a significant drawback, especially in hub-and-spoke networks. To better understand the drawbacks of this feature, refer to the EIGRP hub-and-spoke network in Figure 36.14 below:

The topology in Figure 36.14 illustrates a classic hub-and-spoke network, with router HQ as the hub router and routers S1 and S2 as the two spoke routers. On the Frame Relay WAN, each spoke router has a single DLCI provisioned between itself and the HQ router in a partial-mesh topology. The Frame Relay configuration on the routers is verified as follows:

HQ#show frame-relay map
Serial0/0 (up): ip 172.16.1.2 dlci 102(0x66,0x1860), static,
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 172.16.1.1 dlci 103(0x67,0x1870), static,
              broadcast,
              CISCO, status defined, active
S1#show frame-relay map
Serial0/0 (up): ip 172.16.1.2 dlci 301(0x12D,0x48D0), static,
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 172.16.1.3 dlci 301(0x12D,0x48D0), static,
              broadcast,
              CISCO, status defined, active
S2#show frame-relay map
Serial0/0 (up): ip 172.16.1.1 dlci 201(0xC9,0x3090), static,
              broadcast,
              CISCO, status defined, active
Serial0/0 (up): ip 172.16.1.3 dlci 201(0xC9,0x3090), static,
              broadcast,
              CISCO, status defined, active

We will cover Frame Relay later on in the WAN section. Enhanced IGRP has been enabled on all three routers, using AS 150. The following output illustrates the EIGRP neighbour relationships between the HQ router and the spoke routers:

HQ#show ip eigrp neighbors
IP-EIGRP neighbors for process 150
H   Address        Interface     Hold  Uptime   SRTT  RTO  Q   Seq
(sec)           (ms)       Cnt Num
1   172.16.1.1     Se0/0         165   00:01:07 24    200  0   2
0   172.16.1.2     Se0/0         153   00:01:25 124   744  0   2

The following output illustrates the EIGRP neighbour relationship between the first spoke router, S1, and the HQ router:

S1#show ip eigrp neighbors
IP-EIGRP neighbors for process 150
H   Address       Interface     Hold  Uptime   SRTT RTO   Q   Seq
                                (sec)           (ms)       Cnt Num
0   172.16.1.3    Se0/0         128   00:00:53 911  5000  0   4

The following output illustrates the EIGRP neighbour relationship between the second spoke router, S2, and the HQ router:

S2#show ip eigrp neighbors
IP-EIGRP neighbors for process 150
H   Address       Interface     Hold   Uptime   SRTT  RTO  Q   Seq
                                (sec)            (ms)       Cnt Num
0   172.16.1.3    Se0/0         156    00:02:20 8     200  0   4

By default, EIGRP split horizon is enabled, which is undesirable in partial-mesh NBMA networks. This means that the HQ router will not advertise routing information learned on Serial0/0 out of the same interface. The effect of this default behaviour is that the HQ router will not advertise the 10.1.1.0/24 prefix received from S1 to S2 because the route is received via theSerial0/0 interface, and the split horizon feature prevents the router from advertising information learned on that interface back out onto the same interface. The same is also applicable for the 10.2.2.0/24 prefix the HQ router receives from S2.

This default behaviour means that while the HQ router is aware of both prefixes, the spoke routers have only partial routing tables. The routing table on the HQ router is as follows:

HQ#show ip route eigrp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.1.1.0/24 [90/2195456] via 172.16.1.1, 00:12:04, Serial0/0
D       10.2.2.0/24 [90/2195456] via 172.16.1.2, 00:12:06, Serial0/0

The routing table on spoke S1 is as follows:

S1#show ip route eigrp
192.168.1.0/26 is subnetted, 1 subnets
D       192.168.1.0 [90/2195456] via 172.16.1.3, 00:10:53, Serial0/0

The routing table on spoke S2 is as follows:

S2#show ip route eigrp
192.168.1.0/26 is subnetted, 1 subnets
D       192.168.1.0 [90/2195456] via 172.16.1.3, 00:10:55, Serial0/0

The result of this default behaviour is that while the HQ router will be able to reach both of the spoke router networks, neither spoke router will be able to reach the network of the other. There are several ways such a situation can be addressed and they are as follows:

• Disabling split horizon on the HQ (hub) router
• Advertising a default route from the HQ router to the spoke routers
• Manually configuring EIGRP neighbours on the routers

Disabling split horizon is performed at the interface level using the no ip split-horizon eigrp [AS] interface configuration command on the hub router. The command show ip split-horizon interface_name does not show the state of EIGRP split horizon as it does for RIP. To see if it is disabled, you have to examine the interface configuration section (i.e, show run interface_name). Referencing the network topology illustrated in Figure 36.14 above, this interface configuration command would be applied to the Serial0/0 interface on the HQ router. This is performed as follows:

HQ(config)#interface Serial0/0
HQ(config-if)#no ip split-horizon eigrp 150

After split horizon is disabled, the HQ router can advertise information back out onto the same interface on which it was received. For example, the routing table on spoke S2 now shows a routing entry for the 10.1.1.0/24 prefix advertised by spoke S1 to the HQ router:

S2#show ip route eigrp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.1.1.0/24 [90/2707456] via 172.16.1.3, 00:00:47, Serial0/0
192.168.1.0/26 is subnetted, 1 subnets
D       192.168.1.0 [90/2195456] via 172.16.1.3, 00:00:47, Serial0/0

A simple ping test from spoke router S2 to the 10.1.1.0/24 subnet can be used to verify connectivity, as illustrated below:

S2#ping 10.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/27/32 ms

The second method of disabling split horizon is simply to advertise a default route from the HQ router to the spoke routers. In this situation, the ip summary-address eigrp 150 0.0.0.0 0.0.0.0 interface configuration command could be applied to the Serial0/0 interface of the HQ router. This would allow the spoke routers to reach each other through the HQ router, which contains the full routing table, negating the need to disable split horizon.

The final alternative method of disabling split horizon is to configure manually EIGRP neighbour statements on all routers using the neighbor router configuration command. Because updates between neighbours are Unicast when this configuration is used, the split horizon limitation is removed. This option works well in small networks; however, as the network grows and the number of spoke routers increases, so does the configuration overhead.

Given that the configuration of both EIGRP default routing and static neighbours was described in detail in earlier sections in this module, the configuration of these features is omitted for brevity.

EIGRP Route Summarisation

Route summarisation reduces the amount of information that routers must process, which allows for faster convergence within the network. Summarisation also restricts the size of the area that is affected by network changes by hiding detailed topology information from certain areas within the network. Finally, as was stated earlier in this module, summarisation is used to define a Query boundary for EIGRP, which supports two types of route summarisation, as follows:

• Automatic route summarisation
• Manual route summarisation

By default, automatic route summarisation is in effect when EIGRP is enabled on the router. This is implemented using the auto-summary command. This command allows EIGRP to perform automatic route summarisation at classful boundaries. The operation of this default feature is illustrated referencing the network topology in Figure 36.15 below:

Referencing the EIGRP network illustrated in Figure 36.15, R1 and R2 are running EIGRP and are using autonomous system 150. The 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 subnets are directly connected to R1. R1 is advertising these routes to R2. R1 and R2 are connected using a back-to-back Serial connection on the 150.1.1.0/24 subnet (which is a different major network than the 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 subnets). Based on the networks connected to these routers, by default, EIGRP will perform automatic summarisation, as follows:

• The 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 subnets will be summarised to 10.0.0.0/8
• The 150.1.1.0/24 subnet will be summarised to 150.1.0.0/16

This default behaviour can be validated by viewing the output of the show ip protocols command. The output of this command on R1 is illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    150.1.0.0/16 for Loopback1, Loopback2, Loopback3
      Summarizing with metric 2169856
  10.0.0.0/8 for Serial0/0
      Summarizing with metric 128256
  Maximum path: 4
  Routing for Networks:
    10.1.1.0/24
    10.2.2.0/24
    10.3.3.0/24
    150.1.1.0/24
  Routing Information Sources:
    Gateway         Distance      Last Update
    (this router)         90      00:03:12
    150.1.1.2             90      00:03:12
  Distance: internal 90 external 170

In the output above, the 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 subnets have been automatically summarised to 10.0.0.0/8. This summary address is advertised out of Serial0/0. The 150.1.1.0/24 subnet has been summarised to 150.1.0.0/16. This summary address is advertised out of Loopback1, Loopback2, and Loopback3. Remember, by default, EIGRP will send out updates on all interfaces for which EIGRP routing is enabled.

Referencing the output printed above, you can see that sending updates on a Loopback interface is a waste of resources because a device cannot be connected physically to a router Loopback interface listening for such updates. This default behaviour can be disabled by using the passive-interface router configuration command, as follows:

R1(config)#router eigrp 150
R1(config-router)#passive-interface Loopback1
R1(config-router)#passive-interface Loopback2
R1(config-router)#passive-interface Loopback3
R1(config-router)#exit

The result of this configuration is that EIGRP packets are no longer sent out of the Loopback interfaces. Therefore, as illustrated below, the summary address is not advertised out of these interfaces:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    10.0.0.0/8 for Serial0/0
      Summarizing with metric 128256
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
    150.1.0.0
  Passive Interface(s):
    Loopback0
    Loopback1
    Loopback2
    Loopback3
  Routing Information Sources:
    Gateway         Distance      Last Update
    (this router)         90      00:03:07
    150.1.1.2             90      00:01:12
  Distance: internal 90 external 170

NOTE: The passive-interface command is described in detail later in this module.

Continuing with automatic summarisation, following automatic summarisation at the classful boundary, EIGRP installs a route to the summary address into the EIGRP topology table and the IP routing table. The route is highlighted below in the EIGRP topology table, along with the more specific entries and their respective directly connected interfaces:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.0.0.0/8, 1 successors, FD is 128256
        via Summary (128256/0), Null0
P 10.3.3.0/24, 1 successors, FD is 128256
        via Connected, Loopback3
P 10.2.2.0/24, 1 successors, FD is 128256
        via Connected, Loopback2
P 10.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback1
...
[Truncated Output]

In the routing table, the summary route is connected directly to the Null0 interface. The route has a default administrative distance value of 5. This is illustrated in the following output:

R1#show ip route 10.0.0.0 255.0.0.0
Routing entry for 10.0.0.0/8
  Known via “eigrp 150”, distance 5, metric 128256, type internal
  Redistributing via eigrp 150
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 128256, traffic share count is 1
      Total delay is 5000 microseconds, minimum bandwidth is 10000000 Kbit
      Reliability 255/255, minimum MTU 1514 bytes
      Loading 1/255, Hops 0

When EIGRP performs automatic summarisation, the router advertises the summary route and suppresses the more specific routes. In other words, while the summary route is advertised, the more specific prefixes are suppressed in updates to EIGRP neighbours. This can be validated by looking at the routing table on R2, as illustrated below:

R2#show ip route eigrp
D    10.0.0.0/8 [90/2298856] via 150.1.1.1, 00:29:05, Serial0/0

This default behaviour works well in basic networks, such as the one illustrated in Figure 36.15 above. However, it can have an adverse impact in a discontiguous network, which comprises a major network that separates another major network, as illustrated in Figure 36.16 below:

Referencing the diagram illustrated in Figure 36.16, the major 150.1.0.0/16 network separates the two major 10.0.0.0/8 networks. When automatic summarisation is enabled, both R1 and R2 will summarise the 10.1.1.0/24 and 10.2.2.0/24 subnets, respectively, to the 10.0.0.0/8 address. This summary route will be installed with a next-hop interface of Null0. The Null0 interface is a “bit-bucket.” Any packets sent to this interface are effectively discarded.

Because both routers advertise to each other only the summary addresses, neither router will be able to reach the 10.x.x.x/24 subnet of the other router. To understand the ramifications of automatic summarisation in the network illustrated in Figure 36.16, let’s go through the steps one at a time, beginning with the configuration on R1 and R2, which is as follows:

R1(config)#router eigrp 150
R1(config-router)#network 10.1.1.0 0.0.0.255
R1(config-router)#network 150.1.1.0 0.0.0.255
R1(config-router)#exit

R2(config)#router eigrp 150
R2(config-router)#network 10.2.2.0 0.0.0.255
R2(config-router)#network 150.1.1.0 0.0.0.255
R2(config-router)#exit

Because automatic summarisation at the classful boundary is enabled by default on both of the routers, they will both generate two summary addresses: one for 10.0.0.0/8 and another for 150.1.0.0/16. These summary addresses will both point to the Null0 interface, and the routing table on R1 will display the following entries:

R1#show ip route eigrp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:04:51, Null0
150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       150.1.0.0/16 is a summary, 00:06:22, Null0

Similarly, the routing table on R2 also reflects the same, as follows:

R2#show ip route eigrp
10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:01:58, Null0
150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       150.1.0.0/16 is a summary, 00:01:58, Null0

Even though a summary address of 150.1.0.0/16 has been installed into the IP routing table, R1 and R2 are still able to ping each other because the more route-specific entry (150.1.1.0/24) resides on a directly connected interface. The more specific entries in a summary route can be viewed by issuing the show ip route [address][mask] longer-prefixes command. The output of this command is illustrated below for the 150.1.0.0/16 summary:

R1#show ip route 150.1.0.0 255.255.0.0 longer-prefixes
Codes: 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
Gateway of last resort is not set
        150.1.0.0/16 is variably subnetted, 2 subnets, 2 masks
C       150.1.1.0/24 is directly connected, Serial0/0
D       150.1.0.0/16 is a summary, 00:10:29, Null0

Because the more specific 150.1.1.0/24 route entry exists, packets sent to the 150.1.1.2 address will be forwarded via the Serial0/0 interface. This allows connectivity between R1 and R2, a illustrated below:

R1#ping 150.1.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 150.1.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

However, packets to any other subnets of the major 150.1.0.0/16 network will be sent to the Null0 interface because no specific route entries exist.

So far, everything appears to be in order. You can see that due to the more specific route entry of the major 150.1.0.0/16 network, R1 and R2 are able to ping each other. The problem, however, is connectivity between the major 10.0.0.0/8 subnets on R1 and R2. Router R1 displays the following specific route entries for its generated 10.0.0.0/8 summary address:

R1#show ip route 10.0.0.0 255.0.0.0 longer-prefixes
Codes: 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
Gateway of last resort is not set
        10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.1.1.0/24 is directly connected, FastEthernet0/0
D       10.0.0.0/8 is a summary, 00:14:23, Null0

Similarly, router R2 displays the following specific entries for its generated 10.0.0.0/8 summary:

R2#show ip route 10.0.0.0 255.0.0.0 longer-prefixes
Codes: 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
Gateway of last resort is not set
        10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
C       10.2.2.0/24 is directly connected, FastEthernet0/0
D       10.0.0.0/8 is a summary, 00:15:11, Null0

Neither router has a route to the other router’s 10.x.x.x/24 subnet. If, for example, R1 attempts to send packets to 10.2.2.0/24, the summary address will be used and the packets will be forwarded to the Null0 interface. This is illustrated in the following output:

R1#show ip route 10.2.2.0
Routing entry for 10.0.0.0/8
  Known via “eigrp 150”, distance 5, metric 28160, type internal
  Redistributing via eigrp 150
  Routing Descriptor Blocks:
  * directly connected, via Null0
      Route metric is 28160, traffic share count is 1
      Total delay is 100 microseconds, minimum bandwidth is 100000 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 0

R1 will be unable to ping the 10.x.x.x/24 subnet on R2 and vice-versa, as illustrated below:

R1#ping 10.2.2.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.2.2.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

Two solutions to this issue are as follows:

• Manually configure static routes for the 10.x.x.x/24 subnets on both routers
• Disable EIGRP automatic classful network summarisation

The first option is very basic. However, static route configuration is not scalable and requires a great deal of configuration overhead in large networks. The second option, which is also the recommended option, is both scalable and requires less configuration overhead than the first. Automatic summarisation is disabled by issuing the no auto-summary command (disabled by default in newer IOS releases), as illustrated below:

R1(config)#router eigrp 150
R1(config-router)#no auto-summary
R1(config-router)#exit

R2(config)#router eigrp 150
R2(config-router)#no auto-summary
R2(config-router)#exit

The result of this configuration is that the specific subnets of the major network are advertised by both routers. A summary route is not generated, as illustrated below:

R2#show ip route eigrp
10.0.0.0/24 is subnetted, 2 subnets
D       10.1.1.0 [90/2172416] via 150.1.1.1, 00:01:17, Serial0/0

IP connectivity between the 10.x.x.x/24 subnets can be validated using a simple ping, as illustrated below:

R2#ping 10.1.1.1 source 10.2.2.2 repeat 10
Type escape sequence to abort.
Sending 10, 100-byte ICMP Echos to 10.1.1.1, timeout is 2 seconds:
Packet sent with a source address of 10.2.2.2
!!!!!!!!!!
Success rate is 100 percent (10/10), round-trip min/avg/max = 1/3/4 ms

Before we go into the details pertaining to manual route summarisation, it is important to know that EIGRP will not automatically summarise external networks unless there is an internal network that will be included in the summary. To better understand this concept, refer to Figure 36.17 below, which illustrates a basic EIGRP network:

Referencing Figure 36.17, R1 is redistributing (which makes them external) and then advertising the 10.0.0.0/24, 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 external networks via EIGRP. Automatic route summarisation is enabled on R1. The initial configuration on R1 is as follows:

R1(config)#router eigrp 150
R1(config-router)#redistribute connected metric 8000000 5000 255 1 1514
R1(config-router)#network 150.1.1.1 0.0.0.0
R1(config-router)#exit

The show ip protocols command shows that EIGRP is enabled for Serial0/0 and is redistributing connected networks. Automatic summarisation is also enabled, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: connected, eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Maximum path: 4
  Routing for Networks:
    150.1.1.1/32
Routing Information Sources:
    Gateway         Distance      Last Update
    150.1.1.2             90      00:00:07
  Distance: internal 90 external 170

Because the 10.x.x.x/24 prefixes are all external routes, EIGRP will not automatically summarise these prefixes, as illustrated in the previous example. Therefore, EIGRP will not add a summary route to either the topology table or the IP routing table for these entries. This is illustrated in the following output:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.0.0.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
P 10.1.1.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
P 10.2.2.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
P 10.3.3.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
...
[Truncated Output]

The specific route entries are advertised to R2 as external EIGRP routes, as illustrated below:

R2#show ip route eigrp
10.0.0.0/24 is subnetted, 4 subnets
D EX    10.3.3.0 [170/3449856] via 150.1.1.1, 00:07:02, Serial0/0
D EX    10.2.2.0 [170/3449856] via 150.1.1.1, 00:07:02, Serial0/0
D EX    10.1.1.0 [170/3449856] via 150.1.1.1, 00:07:02, Serial0/0
D EX    10.0.0.0 [170/3449856] via 150.1.1.1, 00:07:02, Serial0/0

Now, assume that the 10.0.0.0/24 subnet is an internal network, while the 10.1.1.0/24, 10.2.2.0/24, and 10.3.3.0/24 subnets are external routes. Because one of the routes that will comprise the classful summary address 10.0.0.0/8 is an internal route, EIGRP will create a summary address and include that in the EIGRP topology table and the IP routing table. The show ip protocols command shows that the 10.0.0.0/24 network is now an internal EIGRP network, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: connected, eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is in effect
  Automatic address summarization:
    150.1.0.0/16 for Loopback0
      Summarizing with metric 2169856
    10.0.0.0/8 for Serial0/0
      Summarizing with metric 128256
  Maximum path: 4
  Routing for Networks:
    10.0.0.1/32
    150.1.1.1/32
  Routing Information Sources:
    Gateway         Distance      Last Update
    (this router)         90      00:00:05
    150.1.1.2             90      00:00:02
  Distance: internal 90 external 170

In the output above, EIGRP automatic summarisation has generated a summary address for 10.0.0.0/8 because the 10.0.0.0/24 internal subnet is a part of the aggregate address. The EIGRP topology table displays the external and internal entries, as well as the summary address, as illustrated below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.0.0.0/8, 1 successors, FD is 128256
        via Summary (128256/0), Null0
P 10.0.0.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 10.1.1.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
P 10.2.2.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
P 10.3.3.0/24, 1 successors, FD is 1280256
        via Rconnected (1280256/0)
...
[Truncated Output]

This time, only a single route is advertised to R2, as illustrated in the following output:

R2#show ip route eigrp
D    10.0.0.0/8 [90/2297856] via 150.1.1.1, 00:04:05, Serial0/0

From the perspective of R2, this is simply an internal EIGRP route. In other words, the router does not have any knowledge that the summary address is also comprised of external routes, as illustrated below:

R2#show ip route 10.0.0.0 255.0.0.0
Routing entry for 10.0.0.0/8
  Known via “eigrp 150”, distance 90, metric 2297856, type internal
  Redistributing via eigrp 150
  Last update from 150.1.1.1 on Serial0/0, 00:05:34 ago
  Routing Descriptor Blocks:
  * 150.1.1.1, from 150.1.1.1, 00:05:34 ago, via Serial0/0
      Route metric is 2297856, traffic share count is 1
      Total delay is 25000 microseconds, minimum bandwidth is 1544 Kbit
      Reliability 255/255, minimum MTU 1500 bytes
      Loading 1/255, Hops 1

R2 is able to reach both the internal 10.0.0.0/24 network and the other external 10.x.x.x/24 networks via the received summary route, as illustrated below:

R2#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms

R2#ping 10.3.3.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.3.3.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Unlike EIGRP automatic summarisation, EIGRP manual route summarisation is configured and implemented at the interface level using the ip summary-address eigrp [ASN] [network] [mask] [distance] [leak-map <name>] interface configuration command. By default, an EIGRP summary address is assigned a default administrative distance value of 5. This default assignment can be changed by specifying the desired administrative distance value as specified by the [distance] keyword.

By default, when manual route summarisation is configured, EIGRP will not advertise the more specific route entries that fall within the summarised network entry. The [leak-map <name>] keyword can be configured to allow EIGRP route leaking, wherein EIGRP allows specified specific route entries to be advertised in conjunction with the summary address. Those entries that are not specified in the leak map are still suppressed.

When manually summarising routes, it is important to be as specific as possible. Otherwise, the configuration might result in a black-holing of traffic in a manner similar to the example pertaining to discontiguous networks that was described earlier. This concept is illustrated in Figure 36.18 below:

Referencing Figure 36.18, if a manual summary address of 10.0.0.0/8 is configured on both of the routers, then the more specific prefixes are suppressed. Because EIGRP also installs a route to the summary address into both the EIGRP topology table and the IP routing table with a next-hop interface of Null0, the same issue experienced with automatic summarisation in discontiguous networks is experienced in this network, and the respective subnets on either router will be unable to communicate with each other.

Additionally, it is also important to understand that if poorly implemented within the network, route summarisation may result in suboptimal routing within the network. This concept is illustrated in Figure 36.19 below:

By default, when a summary route is created for EIGRP, the router advertises the summary address with a metric equal to the minimum of all the more specific routes. In other words, the summary address will have the same metric as the lowest, most specific route included in the creation of the summary address.

Referencing the network topology illustrated in Figure 36.19, both R2 and R3 are advertising the summary address 10.0.0.0/8 to R1. This summary is comprised of the more specific 10.4.4.0/24 and 10.6.6.0/24 prefixes. The metric used by the summary address on both routers is calculated as illustrated below in Table 36.5:

Table 36.5 – Summary Route Metric Calculation

Based on the metric calculation in Table 36.5, R2 clearly has the lowest metric path to 10.4.4.0/24 for traffic originating from R1, while R3 has the lowest metric path to 10.6.6.0/24 for traffic originating from R1. However, when the 10.0.0.0/8 summary address is advertised to R1, the summary address uses the lowest minimum metric of all routes of which the summary is comprised. Based on this example, R2 advertises the summary address to R1 with a metric of 10. R3 follows the same logic and advertises the summary route to R1 with a metric of 15.

When R1 receives the summary routes from R2 and R3, it uses the one with the lowest metric to forward traffic destined to subnets contained within the 10.0.0.0/8 major classful network via R2. This is illustrated in Figure 36.20 below:

Referencing Figure 36.20, you can clearly see that while this is the optimal path for the 10.4.4.0/24 subnet, it is a suboptimal path for the 10.6.6.0/24 subnet. It is therefore very important to understand the network topology before implementing route summarisation in the network.

Reverting back to the configuration of manual route summarisation when using EIGRP, the network topology illustrated in Figure 36.21 below will be used to demonstrate manual route summarisation and route leaking:

Based on the interfaces configured on R1, the routing table on R2 displays the following entries:

R2#show ip route eigrp
10.0.0.0/24 is subnetted, 4 subnets
D       10.3.3.0 [90/2297856] via 150.1.1.1, 00:00:14, Serial0/0
D       10.2.2.0 [90/2297856] via 150.1.1.1, 00:00:14, Serial0/0
D       10.1.1.0 [90/2297856] via 150.1.1.1, 00:00:14, Serial0/0
D       10.0.0.0 [90/2297856] via 150.1.1.1, 00:00:14, Serial0/0

To summarise these entries on R1 and to advertise a single specific route, the following configuration is applied to the Serial0/0 interface of R1:

R1(config)#interface Serial0/0
R1(config-if)#ip summary-address eigrp 150 10.0.0.0 255.252.0.0
R1(config-if)#exit

Following this configuration, the summary entry 10.0.0.0/14 is installed into the EIGRP topology table and the IP routing table on R1. The EIGRP topology table entry is as follows:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.0.0.0/14, 1 successors, FD is 128256
        via Summary (128256/0), Null0
P 10.3.3.0/24, 1 successors, FD is 128256
        via Connected, Loopback3
P 10.2.2.0/24, 1 successors, FD is 128256
        via Connected, Loopback2
P 10.0.0.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 10.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback1
...
[Truncated Output]

The routing table entry also reflects the summary route with a next-hop interface of Null0, as illustrated below:

R1#show ip route
Codes: 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
Gateway of last resort is not set
         10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       10.3.3.0/24 is directly connected, Loopback3
C       10.2.2.0/24 is directly connected, Loopback2
C       10.1.1.0/24 is directly connected, Loopback1
C       10.0.0.0/24 is directly connected, Loopback0
D*      10.0.0.0/14 is a summary, 00:02:37, Null0
     150.1.0.0/24 is subnetted, 1 subnets
C       150.1.1.0 is directly connected, Serial0/0
     150.2.0.0/24 is subnetted, 1 subnets
C       150.2.2.0 is directly connected, Serial0/1

Again, the show ip route [address] [mask] longer-prefixes command can be used to view the specific route entries that comprise the aggregate or summary route, as illustrated in the following output on R1:

R1#show ip route 10.0.0.0 255.252.0.0 longer-prefixes
Codes: 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
Gateway of last resort is not set
         10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks
C       10.3.3.0/24 is directly connected, Loopback3
C       10.2.2.0/24 is directly connected, Loopback2
C       10.1.1.0/24 is directly connected, Loopback1
C       10.0.0.0/24 is directly connected, Loopback0
D       10.0.0.0/14 is a summary, 00:04:03, Null0

On R2, a single route entry for the 10.0.0.0/14 summary address is received, as illustrated below:

R2#show ip route eigrp
     10.0.0.0/14 is subnetted, 1 subnets
D       10.0.0.0 [90/2297856] via 150.1.1.1, 00:06:22, Serial0/0

To reinforce the concept regarding the metric for the summary route, assume that the routes on R1 are all external EIGRP routes (i.e., they have been redistributed into EIGRP) with different metrics. The EIGRP topology table on R1 displays the following:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.0.0.0/24, 1 successors, FD is 10127872
        via Rconnected (10127872/0)
P 10.1.1.0/24, 1 successors, FD is 3461120
        via Rconnected (3461120/0)
P 10.2.2.0/24, 1 successors, FD is 2627840
        via Rconnected (2627840/0)
P 10.3.3.0/24, 1 successors, FD is 1377792
        via Rconnected (1377792/0)
...
[Truncated Output]

The same summary address configured on R1 in the previous example is configured again as follows:

R1(config)#int s0/0
R1(config-if)#ip summary-address eigrp 150 10.0.0.0 255.252.0.0
R1(config-if)#exit

Based on this configuration, the summary route is placed into the EIGRP topology table and the IP routing table with a metric equal to the lowest metric of all routes that it encompasses. Based on the output of the show ip eigrp topology command shown previously, the summary address will be assigned the same metric assigned to the 10.3.3.0/24 prefix, as illustrated below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.0.0.0/14, 1 successors, FD is 1377792
        via Summary (1377792/0), Null0
P 10.0.0.0/24, 1 successors, FD is 10127872
        via Rconnected (10127872/0)
P 10.1.1.0/24, 1 successors, FD is 3461120
        via Rconnected (3461120/0)
P 10.2.2.0/24, 1 successors, FD is 2627840
        via Rconnected (2627840/0)
P 10.3.3.0/24, 1 successors, FD is 1377792
        via Rconnected (1377792/0)
P 150.1.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0

Understanding Passive Interfaces

As stated earlier in this module, when EIGRP is enabled for a network, the router begins to send out Hello packets on all interfaces that fall within the specified network range. This allows EIGRP to discover neighbours dynamically and establish network relationships. This is desired on interfaces that are actually connected to physical media, such as Ethernet and Serial interfaces. However, this default behaviour also results in an unnecessary waste of router resources on logical interfaces, such as Loopback interfaces, that will never have any other device connected to them with which the router could ever establish an EIGRP neighbour relationship.

Cisco IOS software allows administrators to use the passive-interface [name|default] router configuration command to specify the named interface as passive, or all interfaces as passive. EIGRP packets are not sent out on passive interfaces; therefore, no neighbour relationship will ever be established between passive interfaces. The following output illustrates how to configure two EIGRP-enabled interfaces as passive on a router:

R1(config)#interface Loopback0
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface Loopback1
R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface Serial0/0
R1(config-if)#ip address 150.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#router eigrp 150
R1(config-router)#no auto-summary
R1(config-router)#network 150.1.1.0 0.0.0.255
R1(config-router)#network 10.0.0.0 0.0.0.255
R1(config-router)#network 10.1.1.0 0.0.0.255
R1(config-router)#passive-interface Loopback0
R1(config-router)#passive-interface Loopback1
R1(config-router)#exit

Based on this configuration, Loopback0 and Loopback1 are enabled for EIGRP routing and the directly connected networks will be advertised to EIGRP neighbours. However, no EIGRP packets will be sent by R1 out of these interfaces. Serial0/0, on the other hand, is also configured for EIGRP routing, but EIGRP is allowed to send packets on this interface because it is not a passive interface. All three network entries are installed in the EIGRP topology table, as illustrated below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback1
P 10.0.0.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 150.1.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0

However, the output of the show ip eigrp interfaces command shows that EIGRP routing is enabled only for the Serial0/0 interface, as illustrated below:

R1#show ip eigrp interfaces
IP-EIGRP interfaces for process 150
                      Xmit Queue   Mean   Pacing Time   Multicast    Pending
Interface      Peers  Un/Reliable  SRTT   Un/Reliable   Flow Timer   Routes
Se0/0            1        0/0        0       0/15           0           0

You can also view the interfaces configured as passive in the output of the show ip protocols command, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0/24
    10.1.1.0/24
    150.1.1.0/24
  Passive Interface(s):
    Loopback0
    Loopback1
  Routing Information Sources:
    Gateway         Distance      Last Update
  Distance: internal 90 external 170

The [default] keyword makes all interfaces passive. Assume that a router is configured with 50 Loopback interfaces configured. If you wanted to make each Loopback interface passive, you would need to add 50 lines of code. The passive-interface default command can be used to make all interfaces passive. Those interfaces that you do want to send EIGRP packets to can then be configured with the no passive-interface [name] command. The following illustrates the use of the passive-interface default command:

R1(config)#interface Loopback0
R1(config-if)#ip address 10.0.0.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface Loopback1
R1(config-if)#ip address 10.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface Loopback3
R1(config-if)#ip address 10.3.3.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface Loopback2
R1(config-if)#ip address 10.2.2.1 255.255.255.0
R1(config-if)#exit
R1(config)#interface Serial0/0
R1(config-if)#ip address 150.1.1.1 255.255.255.0
R1(config-if)#exit
R1(config)#router eigrp 150
R1(config-router)#network 10.0.0.1 255.255.255.0
R1(config-router)#network 10.1.1.1 255.255.255.0
R1(config-router)#network 10.3.3.1 255.255.255.0
R1(config-router)#network 10.2.2.1 255.255.255.0
R1(config-router)#network 150.1.1.1 255.255.255.0
R1(config-router)#passive-interface default
R1(config-router)#no passive-interface Serial0/0
R1(config-router)#exit

The show ip protocols can be used to view which interfaces are passive under EIGRP, as illustrated below:

R1#show ip protocols
Routing Protocol is “eigrp 150”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
  Redistributing: eigrp 150
  EIGRP NSF-aware route hold timer is 240s
  Automatic network summarization is not in effect
  Maximum path: 4
  Routing for Networks:
    10.0.0.0/24
    10.1.1.0/24
    10.2.2.0/24
    10.3.3.0/24
    150.1.1.0/24
  Passive Interface(s):
    Loopback1
    Loopback2
    Loopback3
    Loopback4
  Routing Information Sources:
    Gateway         Distance      Last Update
    (this router)         90      00:02:52
  Distance: internal 90 external 170

By using the passive-interface default command, the configuration of multiple passive interfaces is simplified and reduced. Used in conjunction with the no passive-interface Serial0/0 command, EIGRP packets are still sent out on Serial0/0, allowing EIGRP neighbour relationships to be established across that interface, as illustrated below:

R1#show ip eigrp neighbors
IP-EIGRP neighbors for process 150
H   Address      Interface  Hold  Uptime    SRTT  RTO    Q     Seq
(sec)           (ms)         Cnt   Num
0   150.1.1.2    Se0/0      12    00:02:47  1     3000   0     69

Understanding the Use of the EIGRP Router ID

Unlike OSPF, which uses the router ID (RID) to identify the OSPF neighbour, the primary use of the EIGRP RID is to prevent routing loops. The RID is used to identify the originating router for external routes. If an external route is received with the same RID as the local router, the route is discarded. This feature is designed to reduce the possibility of routing loops in networks where route redistribution is being performed on more than one ASBR.

When determining the RID, EIGRP will select the highest IP address that is configured on the router. If Loopback interfaces are also configured on the router, those interfaces are preferred, since a Loopback interface is the most stable interface that can exist on a router. The RID will never change unless the EIGRP process is removed (i.e., if the RID is manually configured). The RID will always be listed in the EIGRP topology table, as illustrated below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
P 10.2.2.0/24, 1 successors, FD is 128256
        via Connected, Loopback2
P 10.3.3.0/24, 1 successors, FD is 128256
        via Connected, Loopback3
P 10.1.1.0/24, 1 successors, FD is 128256
        via Connected, Loopback1
P 10.0.0.0/24, 1 successors, FD is 128256
        via Connected, Loopback0
P 150.1.1.0/24, 1 successors, FD is 2169856
        via Connected, Serial0/0

NOTE: It is important to understand that the RID and the neighbour ID will typically be different, although this may not be the case in routers with a single interface, for example.

The EIGRP RID is configured using the eigrp router-id [address] router configuration command. When this command is entered, the RID is automatically updated with the new address in the EIGRP topology table. To demonstrate this point, let’s begin by looking at the current RID on the router, as stated in the topology table below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(10.3.3.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
...
[Truncated Output]

A RID of 1.1.1.1 is now configured on the router, as follows:

R1(config)#router eigrp 150
R1(config-router)#eigrp router-id 1.1.1.1
R1(config-router)#
*Mar 1 05:50:13.642: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 150: Neighbor 150.1.1.2 (Serial0/0) is down: route configuration changed
*Mar 1 05:50:16.014: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 150: Neighbor 150.1.1.2 (Serial0/0) is up: new adjacency

Following the change, the EIGRP neighbour relationship is reset and the new RID is reflected immediately in the EIGRP topology table, as illustrated below:

R1#show ip eigrp topology
IP-EIGRP Topology Table for AS(150)/ID(1.1.1.1)
Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,
       r - reply Status, s - sia Status
...
[Truncated Output]

When configuring the EIGRP RID, the following should be remembered:

• You cannot configure the RID as 0.0.0.0
• You cannot configure the RID as 255.255.255.255

All external routes that are originated by the router now contain the EIGRP RID. This can be verified in the following output of neighbour router R2:

R2#show ip eigrp topology 192.168.254.0/24
IP-EIGRP (AS 150): Topology entry for 192.168.254.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 7289856
  Routing Descriptor Blocks:
  150.1.1.1 (Serial0/0), from 150.1.1.1, Send flag is 0x0
      Composite metric is (7289856/6777856), Route is External
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 220000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1
      External data:
        Originating router is 1.1.1.1
        AS number of route is 0
        External protocol is Connected, external metric is 0
        Administrator tag is 0 (0x00000000)

The RID is not included for internal EIGRP routes, as illustrated in the following output:

R2#show ip eigrp topology 10.3.3.0/24
IP-EIGRP (AS 150): Topology entry for 10.3.3.0/24
  State is Passive, Query origin flag is 1, 1 Successor(s), FD is 2297856
  Routing Descriptor Blocks:
  150.1.1.1 (Serial0/0), from 150.1.1.1, Send flag is 0x0
      Composite metric is (2297856/128256), Route is Internal
      Vector metric:
        Minimum bandwidth is 1544 Kbit
        Total delay is 25000 microseconds
        Reliability is 255/255
        Load is 1/255
        Minimum MTU is 1500
        Hop count is 1

Section 36 Questions

1. You can see the ASN with the show ip _______ command.
2. Every router you want to communicate with in your routing domain must have a different ASN. True or false?
3. What is the purpose of the EIGRP topology table?
4. By default, EIGRP uses the _______ bandwidth on the path to a destination network and the total _______ to compute routing metrics.
5. Dynamic neighbour discovery is performed by sending EIGRP Hello packets to the destination Multicast group address _______.
6. EIGRP packets are sent directly over IP using protocol number _______.
7. To populate the topology table, EIGRP runs the _______ algorithm.
8. The _______ _______ includes both the metric of a network as advertised by the connected neighbour, plus the cost of reaching that particular neighbour.
9. Cisco IOS software supports equal cost load sharing for a default of up to four paths for all routing protocols. True or false?
10. What EIGRP command can be used to enable unequal cost load sharing?

Section 36 Answers

1. protocols.
2. False.
3. The topology table allows all EIGRP routers to have a consistent view of the entire network. All known destination networks and subnets that are advertised by neighbouring EIGRP routers are stored there.
4. Minimum, delay.
5. 224.0.0.10.
6. 88.
7. DUAL.
8. Feasible Distance.
9. True.
10. The variance command.

Section 36 Lab

EIGRP Lab

Topology

Purpose

Learn how to configure basic EIGRP.

Walkthrough

1. 1Configure all IP addresses based on the topology above. Make sure you can ping across
   the Serial link.
2. 2Configure EIGRP with AS 30 on each router.

RouterA(config)#router eigrp 30
RouterA(config-router)#net 172.20.0.0
RouterA(config-router)#net 10.0.0.0
RouterA(config-router)#^Z
RouterA#
RouterB#conf t
Enter configuration commands, one per line. End with CNTL/Z.
RouterB(config)#router eigrp 30
RouterB(config-router)#net 10.0.0.0
%DUAL-5-NBRCHANGE: IP-EIGRP 30: Neighbor 10.0.0.1 (Serial0/1/0) is up: new adjacency
RouterB(config-router)#net 192.168.1.0

3. Check the routing table on each router.

RouterA#sh ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
Gateway of last resort is not set
        10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:01:43, Null0
C       10.0.0.0/30 is directly connected, Serial0/1/0
        172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       172.20.0.0/16 is a summary, 00:01:43, Null0
C       172.20.1.0/24 is directly connected, Loopback0
D       192.168.1.0/24 [90/20640000] via 10.0.0.2, 00:00:49, Serial0/1/0
RouterA
RouterB#show ip route
...
[Truncated Output]
...
        10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:01:21, Null0
C       10.0.0.0/30 is directly connected, Serial0/1/0
D    172.20.0.0/16 [90/20640000] via 10.0.0.1, 00:01:27, Serial0/1/0
        192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks
D       192.168.1.0/24 is a summary, 00:01:21, Null0
C       192.168.1.0/26 is directly connected, Loopback0
RouterB#

4. Check to ensure that each router is auto-summarising each network. Then turn off autosummary on Router B.

RouterB#show ip protocols
Routing Protocol is “eigrp  30”
  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 metric weight K1=1, K2=0, K3=1, K4=0, K5=0
  EIGRP maximum hopcount 100
  EIGRP maximum metric variance 1
Redistributing: eigrp 30
  Automatic network summarization is in effect
  Automatic address summarization:
    192.168.1.0/24 for Serial0/1/0
      Summarizing with metric 128256
    10.0.0.0/8 for Loopback0
      Summarizing with metric 20512000
  Maximum path: 4
  Routing for Networks:
    10.0.0.0
    192.168.1.0
  Routing Information Sources:
    Gateway         Distance      Last Update
    10.0.0.1        90            496078
  Distance: internal 90 external 170
RouterB(config)#router eigrp 30
RouterB(config-router)#no auto-summary

5. Check the routing table on Router A.

RouterA#show ip route
...
[Truncated Output]
...
Gateway of last resort is not set
       10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks
D       10.0.0.0/8 is a summary, 00:00:04, Null0
C       10.0.0.0/30 is directly connected, Serial0/1/0
        172.20.0.0/16 is variably subnetted, 2 subnets, 2 masks
D       172.20.0.0/16 is a summary, 00:00:04, Null0
C       172.20.1.0/24 is directly connected, Loopback0
        192.168.1.0/26 is subnetted, 1 subnets
D       192.168.1.0 [90/20640000] via 10.0.0.2, 00:00:04, Serial0/1/0
RouterA#