Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Understanding Enhanced Interior Gateway Routing Protocol (EIGRP)

Metrics

EIGRP and IGRP use the same equation to calculate their metrics; however, the EIGRP metric is obtained by multiplying the IGRP metric by 256. In other words:

where the IGRP metric is shown in Equation 6-1.

By default, the K values of K1 and K3 are 0; therefore, the EIGRP metric simplifies to this:

Equation 6-1 IGRP Metric

K1, K2, K3, K4, K5 =Constants

Default values: K1 = K3 = 1,K2 = K4 = K5=0

BW = 107/ (min bandwidth along paths in kilobits per second)

Delay = (Sum of delays along paths in milliseconds)/10

Load = Load of interface

Reli = Reliability of the interface

EIGRP is different than IGRP metric by a factor of 256 because of the Metric field: IGRP uses only 24 bits in its update packet for the Metric field, whereas EIGRP uses 32 bits in its update packet for the Metric field. The difference of 8 bits requires the IGRP metric to be multiplied by 256 to obtain the EIGRP metric. For example, if the IGRP metric to a destination network is 8586, the EIGRP metric would be 8586 x 256 = 2,198,016.

EIGRP Neighbor Relationships

Unlike IGRP, EIGRP must establish neighbor relationships before updates are sent out. When an EIGRP process is configured on the router, the router begins to exchange EIGRP hello packets over the multicast address of 224.0.0.10. Neighbor relationships form between routers when they receive each other’s hello packet. Over LAN broadcast media such as Ethernet, Token Ring, or FDDI, the hello packets are sent every 5 seconds. Over WAN multipoint interfaces with a bandwidth of T1 or greater, and over point-to-point sub-interfaces, the hello packets are also sent out every 5 seconds. WAN multipoint interfaces with a bandwidth of T1 or lower are considered to be low-bandwidth interfaces, and the hello packets are sent out every 60 seconds.

Aside from the hello time, there is also a notion of a hold time. The hold time tells the router the maximum time that it will wait to reset a neighbor if hello packets are not received. In other words, if the hold time expires before a hello packet is received, the neighbor rela-tionship will be reset. The default value of the hold time is three times the hello time. This means that in the LAN broadcast media where the hello time is 5 seconds, the hold time will be 15 seconds, and the slow WAN interfaces with a hello time of 60 seconds will have a default hold time of 180 seconds. Keep in mind that you can configure the hello and hold times. Certain conditions must be met before EIGRP routers consider establishing a neighbor relationship:

The receiving router compares the source address of the hello packet with the IP address of the interface where the packet was received, to ensure that they belong to the same subnet.

The receiving router compares the K constant values of the source router to its own, to make sure that they match.

The receiving router must be within the same autonomous system number as the source router.

Example 6-1 shows the output of the show ip eigrp neighbor command when the neighbor relationship is fully established.

Example 6-1 show ip eigrp neighbor Command Output

Router_1#show ip eigrp neighbor
IP-EIGRP neighbors for process 1
H Address Interface Hold Uptime SRTT RTO Q Seq
(sec) (ms) Cnt Num
1 5.5.5.4 Et0 11 00:00:22 1 4500 0 3
0 192.168.9.5 Et1 10 00:00:23 372 2232 0 2

The explanations of the heading of the output are as follows:

• H— The list of the neighbors in the order in which they are learned.
• Address— The IP address of the neighbors.
• Interface— The interface from which the neighbors are learned.
• Hold— The hold timer for the neighbor. If this timer reaches 0, the neighbor relationship is torn down.
• Uptime— The timer that tracks how long this neighbor has been established.
• SRTT (Smooth Round Trip Time)— The average time in which a reliable EIGRP packet is sent and received.
• RTO (Round Trip Timeout)— How long the router will wait to retransmit the EIGRP reliable packet if acknowledgment is not received.
• Q Count— The number of EIGRP packets waiting to be sent to the neighbor.
• Sequence Number— The sequence number of the last EIGRP reliable packets being received from the neighbor. This is to ensure that packets received from the neighbor are in order.

The Diffusing Update Algorithm
The Diffusing Update Algorithm (DUAL) is the brain behind the operation of EIGRP. It is an algorithm that tracks all the routes advertised from a neighbor and then selects a loop-free path to the destination. Before discussing the details of DUAL, you must understand several terms and concepts:

• Feasible distance (FD)— Feasible distance is the minimum metric along the path to a destination. Figure 6-1 shows the feasible distance calculation to reach Network 7 for each of Router A’s neighbors, from Router A’s perspective.

• Reported distance (RD)— Reported distance, sometimes also known as advertised distance, is the metric toward the destination, as advertised by the upstream neighbor. In other words, the reported distance is the neighbor’s metric going to the destination. Figure 6-2 shows the reported distance calculation to reach Network 7 for each of Router A’s neighbors.

• Feasibility condition (FC)— The feasibility condition (FC) is a condition in which the reported distance (RD) is less than the feasible distance (FD). In other words, the feasibility condition is met when the neighbor’s metric to a destination is less than the local router’s metric. This condition is important to ensure a loop-free path.
• EIGRP successor— A successor is a neighbor that met the feasibility condition (FC) and has the lowest metric toward the destination. A successor is used as the next hop to forward the packet going to the destination network.
• Feasible successor— A feasible successor is a neighbor that satisfies the feasibility condition (FC) but is not selected as the successor. The feasible successor can be thought of as a potential backup route when the primary route goes away.

Figure 6-3 illustrates the concepts of successor and feasible successor.

Router B is chosen as the successor because Router B has the lowest feasible distance (metric = 121) to Network 7 among all of Router A’s neighbors. To select a feasible successor, Router A sees which neighbor has a reported distance (RD) that is less than the feasible distance of its successor. In this case, Router H has a reported distance of 30, which is less than the feasible distance of its successor, which is 121. Therefore, Router H is chosen as the feasible successor. Router D is neither a successor nor a feasible successor because its reported distance is 140, which is larger than 121 and thus does not satisfies the feasibility condition.

• Passive route— A passive route in EIGRP indicates that the router has a valid successor to a destination and EIGRP has no complaints.
• Active route— An active route in EIGRP indicates that the router has lost its successor, it doesn’t have any feasible successor available, and the router is currently actively searching for alternate routes to converge.

DUAL Finite-State Machine

When EIGRP loses its successor or primary route, EIGRP immediately tries to reconverge by looking at its topology table to see if any feasible successors are available. If a feasible successor is available, EIGRP immediately promotes the feasible successor to a successor and informs its neighbors about the change. The feasible successor then becomes the next hop for EIGRP to forward the packets to the destination. The process by which EIGRP converges locally and does not involve other routers in the convergence process is called local computation. This also saves CPU power because all the feasible successors are already chosen before the primary route failures. (Refer to Figure 6-3.) If the primary route (Router D) is not available for some reason, the preselected feasible successor Router H immediately takes over as the primary route.

Now, if the primary route goes away and no feasible successors are available, the router goes into diffused computation. In diffused computation, the router sends query packets to all its neighbors asking for the lost route, and the router goes into Active state. If neighboring routers have information about the lost route, they reply to the querying router. If neighboring routers do not have information about the lost route, they send queries to all their neighbors. If the neighboring router does not have an alternate route and doesn’t have any other neighbors, it sends a reply packet back to the router with a metric set to infinity, indicating that it, too, doesn’t have an alternate route available. The querying router waits for all the replies from all its neighbors and then chooses the neighbor with the best metric in its replies as the next hop to forward packets.

Referring to Figure 6-3, if the primary successor Router B is not available and its feasible successor Router H is also not available, Router A sends a query to Router D asking for Network 7. In this case, Router D simply replies to the query with a valid metric to Network 7. Router A then converges using Router D as its next hop to Network 7.

To sum up the operation of DUAL, DUAL selects a successor as the primary path and also selects a feasible successor as its backup path based on the feasibility condition. If the successor becomes unavailable, the feasible successor is used as the primary route. If the feasible successor is not present, the router queries all its neighbors and computes a new successor based on the replies to the queries. Therefore, in an EIGRP network, the query mechanism is the only means to achieve fast convergence.

Chapter 8 of the Cisco Press book Routing TCP/IP, Volume 1, by Jeff Doyle, provides an excellent, detailed description of the operation of the EIGRP DUAL algorithm.

EIGRP Reliable Transport Protocol

Five types of EIGRP packets exist, further categorized as reliable packets and unreliable packets. The reliable EIGRP packets are as follows:

• Update— Update packets contain EIGRP routing updates sent to an EIGRP neighbor.
• Query— Queries are sent to neighbors when a route is not available and the router needs to ask the status of the route for fast convergence.
• Reply— Reply packets to the queries contain the status of the route being queried for.

The unreliable EIGRP packets are as follows:

• Hello— Hello packets are used to establish EIGRP neighbor relationships across a link.
• Acknowledgment— Acknowledgment packets ensure reliable delivery of EIGRP packets.

All the EIGRP packets are sent through EIGRP multicast address 224.0.0.10. Every EIGRP-enabled device automatically listens to the 224.0.0.10 address. Because this is a multicast address and multiple devices receive the EIGRP packets at once, EIGRP needs its own transport protocol to ensure reliable delivery of EIGRP packets. This protocol is the EIGRP Reliable Transport Protocol (RTP). The router keeps a transmission list for every neighbor. When a reliable EIGRP packet is sent to the neighbor, the sending router expects an acknowledgment to be sent back from the neighbor indicating that the reliable EIGRP packet has been received. EIGRP RTP maintains the transport window size of only one unacknowledged packet. Therefore, every single reliable packet must be acknowledged before the next reliable EIGRP packet can be sent out. The router retransmits the unacknowledged packet until an acknowledgment is received. If no acknowledgment is received, EIGRP RTP retransmits the same packet up to 16 times. If no acknowledgment is received after 16 retransmissions, EIGRP resets the neighbor relationship.

In a multiaccess LAN network, sending a multicast update could pose a problem if the transport window size is 1. As discussed previously, with reliable multicast traffic, the next reliable multicast packet is not transmitted until all peers have acknowledged the previous multicast packet. If one or more EIGRP neighbors in a multiaccess LAN network are slow or fail to acknowledge the EIGRP packet, all the other neighbors will suffer from this.

For example, if there are three routers on an Ethernet segment and Router 1 sends a multicast EIGRP update, it won’t send another multicast EIGRP packet on the Ethernet until it receives an acknowledgment from the other two routers. Now assume that Router 2 successfully sends an acknowledgment packet to Router 1, but Router 3 has a problem sending the acknowledgment packet. Router 1 could potentially stop sending any more EIGRP packets, and Router 2 would be affected even though the problem lies on Router 3. EIGRP RTP avoids this problem by retransmitting the unacknowledged EIGRP packet as a unicast packet to the neighbor that has not acknowledged the previous EIGRP packet, and it continues to send EIGRP multicast packets to the neigh-bor that has already acknowledged the EIGRP packet. The router retransmits the unacknowledged EIGRP packet as a unicast 16 times to a neighbor. If the neighbor still has not acknowledged the EIGRP packet after 16 retries, EIGRP resets the neighbor relationship and the whole process starts over. The 16-retry timeout period usually runs from 50 to 80 seconds.

EIGRP Packet Format

Figure 6-4 shows the EIGRP packet header. Notice that following the autonomous systems number are the Type/Length/Value (TLV) triplets. The TLV triplets carry route entries, as well as provide the fields for DUAL process management. Some common TLVs are the EIGRP parameter TLV, the IP internal route TLV, and the IP external route TLV.

The EIGRP packet parameters are described as follows:

• Version— Specifies different versions of EIGRP. Version 2 of EIGRP was imple-mented beginning with Cisco IOS Software Releases 10.3(11), 11.0(8), and 11.1(3). EIGRP Version 2 is the most recent version that contains many enhancements to improve the stability and scalability of EIGRP.
• Opcode— Specifies the types of EIGRP packet contained. Opcode 1 is the update packet, opcode 3 is the Query, opcode 4 is the reply, and opcode 5 is the EIGRP hello packet.
• Checksum— Used as the regular IP checksum, calculated based on the entire EIGRP packet, excluding the IP header.
• Flags— Involves only two flags now. The flag indicates either an init for new neighbor relationship or the conditional receive for EIGRP RTP.
• Sequence— Specifies the sequence number used by the EIGRP RTP.
• Acknowledgment— Used to acknowledge the receipt of an EIGRP reliable packet.
• Autonomous System Number— Specifies the number for the identification of EIGRP network range.

One of the most common EIGRP TLVs is the EIGRP parameter TLV, as shown in Figure 6-5, which contains the parameter needed to establish a neighbor relationship. The constant K values are included in this TLV, as well as the hold time. The K values between two routers must agree before they can establish a neighbor relationship.

Figure 6-6 and Figure 6-7 show two other common EIGRP TLVs—the IP internal route TLV and the IP external route TLV, respectively. The EIGRP internal routes are routes originated from the same EIGRP autonomous system number as the receiving router. The EIGRP external routes are routes that are being redistributed into the EIGRP autonomous systems.

The EIGRP IP internal route TLV contains this information:

• Next hop— IP address of the next hop to which packets should be forwarded.
• Delay— Delay parameter of the route metric. The delay value is the sum of all the delay parameters on the interface across the path to the destination network.
• Bandwidth— Bandwidth parameter of the route metric. The bandwidth is obtained from the interface, and it is the lowest bandwidth on the interface across the path to the destination network.
• MTU— The interface MTU parameter of the route metric.
• Hop count— Number of hops to the destination network.
• Reliability— The reliability of the interface, out of a possible range of 1 to 255. A reliability of 1 indicates that the reliability is 1/255, whereas a reliability of 255 indicates that the interface is 100 percent reliable.
• Load— The load of the interface, out of a possible range of 1 to 255. A load value of 1 indicates that the interface has a very light load, while a load value of 255 indicates that the interface is highly saturated.
• Prefix length— The subnet mask of the destination network.

In EIGRP IP external route TLV, more information of the route is included:

• Originating router— The router ID of the router that originates the external EIGRP routes.
• Originating autonomous system number— The EIGRP autonomous system number of the routes before getting redistributed into this EIGRP autonomous number.
• External protocol metric— The metric of the routes before getting redistributed into EIGRP.
• External protocol ID— The type of routing protocol that originates the routes that were redistributed into EIGRP. The routing protocol type can be BGP, OSPF, RIP, IGRP, and so forth.

EIGRP Behavior

Unlike IGRP, EIGRP is an advanced distance vector protocol that carries the subnet mask information when an update is sent out. Therefore, EIGRP supports discontiguous network and variable-length subnet masking (VLSM). For more explanation about discontiguous networks and VLSM, refer to Chapter 2, “Understanding Routing Information Protocol (RIP).” Figure 6-8 shows the network diagram that illustrates EIGRP’s support for discontiguous networks.

Figure 6-8 shows two routers connected through a serial port. Router B has the network 192.168.8.128/25 that needs to advertise to Router A across the network 10.1.1.0/24. By default, EIGRP is a classful routing protocol; Router B will autosummarize the route across the major network boundary. Therefore, Router B will advertise 192.168.8.0/24 to Router A, which will ignore this route advertisement. To make EIGRP support discontiguous networks, you must configure the no auto-summary command under the command router eigrp. With the no auto-summary command in place in Router B, Router B will advertise the 192.168.8.128/25 route to Router A, and Router A will have a routing entry for the route. The problem with discontiguous network then will be solved.

EIGRP Summarization

Two types of summarization take place in EIGRP—autosummarization and manual summarization. Autosummarization is the default behavior for EIGRP, just as it is for RIP and IGRP. Basically, when the router sends out a routing update, it automatically summarizes the route to its natural major network when the route is advertised across a major network boundary. Figure 6-9 shows an example of autosummarization. In Figure 6-9, Router R1 needs to send an update about the network 132.168.1.0 to R2 across a major network of 192.168.2.0. R1 then autosummarizes the update to its classful network of 132.168.0.0 and sends it to R2. The problem of autosummarization is that the design of the network cannot be discontiguous.

Manual summarization in EIGRP is configurable on a per-interface basis in any router within the network. The command for EIGRP manual summarization is ip summary-address eigrp autonomous-system-number address mask. With EIGRP, summarization can be done on any interface and any router in the network, compared to OSPF, which can summarize only on an area border router (ABR) and an autonomous system border router (ASBR). When manual summarization is configured on the interface, the router will immediately create a route to null 0 with an administrative distance of 5. This is to prevent routing loops of summary address. Finally, when the last specific route of the summary goes away, the summary route is deleted. Example 6-2 shows the configuration for EIGRP manual summarization for the network in Figure 6-10.

Example 6-2 Configuring EIGRP Manual Summarization

interface s0
ip address 192.168.11.1 255.255.255.252
ip summary-address eigrp 1 192.168.8.0 255.255.252.0

Example 6-2 demonstrates how R1 in Figure 6-10 is summarizing addresses of 192.168.8.0/24, 192.168.9.0/24, and 192.168.10.0/24 into one update of 192.168.8.0/22. Summarization in EIGRP reduces the size of the routing table and the number of updates. It also limits the query range, which is crucial in terms of making a large EIGRP network more stable and more scalable.

EIGRP Query Process

Although EIGRP is an advanced distance vector routing protocol and convergence time is low, an EIGRP router still relies on its neighbor to advertise routing information. To achieve fast convergence, EIGRP can’t rely on a flush timer like IGRP. EIGRP needs to actively search for the lost routes for fast convergence. This process is called the query process, and it was briefly discussed in the previous few sections. In the query process, queries are sent when the primary route is lost and no feasible successors are available. At this stage, the route is said to be in the Active state.

Queries are sent out to all the neighbors and on all interfaces except for the interface to the successor. If the neighboring routers do not have the lost route information, more queries are sent to the neighboring routers’ neighbors until the query boundary is reached. Query boundary consists of either the end of the network, the distribute list boundary, or the summarization boundary. The distribute list and summarization boundaries are defined by the router that has the distribute list or summarization configured. When the queries are sent, the router must wait for all the replies from the neighbors before the router calculates the successor information. If any neighbor fails to reply in three minutes, the route is said to be stuck in active (SIA), and the neighbor relationship of the router that didn’t reply to the query is reset. Chapter 7, “Troubleshooting EIGRP,” addresses the SIA problem and tells how to troubleshoot it in greater detail.

Default Routes and EIGRP

Unlike IGRP, EIGRP recognizes the 0.0.0.0/0 route as the default route and allows it to be redistributed into EIGRP domain as the default route. EIGRP also uses its own method of propagating the default route with the ip default-network command, just as in IGRP.

The ip default-network command works exactly the same as it does in IGRP.

The ip default-network command specifies a major network address and flags it as a default network. This major network could be directly connected, defined by a static route, or discovered by a dynamic routing protocol. Figure 6-11 demonstrates how the ip default-network command works.

In Figure 6-11, Router 1 is connected to the remote site through a DS-3 link. Router 1 now wants to send a default route to Router 2 and to all the routers in the remote site network. In IGRP, the route to 0.0.0.0 is not recognized as a default route; instead, Router 1 must configure ip default-network 192.168.1.0 to flag the route 192.168.1.0 as the default route. Router 1 will send out routing update of 192.168.1.0 and will flag it as a default route. When the routers in the remote site network receive the update for 192.168.1.0, they will mark it as default route and will install the route to 192.168.1.0 as the gateway of last resort.

Unequal-Cost Load Balancing in EIGRP

EIGRP and IGRP use the same equation to calculate their metrics, and they share the same behavior when it comes to unequal-cost load balancing. EIGRP also can install up to six parallel equal-cost paths for load balancing, like IGRP can, and EIGRP also uses the same variance command as IGRP to do unequal-cost path load balancing.

Consider the network in Figure 6-12.

Remember the rules for multipath operation:

• The neighboring router utilized as an alternate pathway must be closer to the destination (that is, it must be advertising a smaller metric than that of the local router for a given destination). It’s not possible to go back to go forward.
• The metric advertised by the neighbor must be less than the variance of the local router’s metric. Variance = Variance Factor 3 Local Metric.

When Router 1 calculates its EIGRP metrics to Router 3, the metric going through the 1544 kbps link is as follows:—————-

The metric going through the 256 kbps link is as follows:

Without unequal-cost load balancing, EIGRP will simply select the 1544 kbps link to forward packets to Router 3, as shown in the output in Example 6-3.

Example 6-3 show ip route Output Shows Router 1 Choosing a Suboptimal Route Without Unequal-Cost Load Balancing

Router_1#show ip route 133.33.0.0
Routing entry for 133.33.0.0/16
Known via "eigrp 1", distance 90, metric 2195456
Redistributing via eigrp 1
Advertised by eigrp 1 (self originated)
Last update from 192.168.6.2 on Serial0, 00:00:20 ago
Routing Descriptor Blocks:
* 192.168.6.2, from 192.168.6.2, 00:00:20 ago, via Serial0
Route metric is2195456, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

To use the unequal-cost load-balancing feature of EIGRP, you use the variance command. Variance is a multiplier in which a metric may be different from the lowest metric to a route. The variance value must be of integer value; the default variance value is 1, meaning that the metrics of multiple routes must be equal to load-balance.

In Example 6-3, the metric through the 256 kbps link is 4.8 times larger than the metric through the 1544 kbps link. Therefore, for the 256 kbps link to be considered in the routing table, a variance of 5 must be configured in Router 1. The configuration in Router 1 is simply variance 5 under the router eigrp command. The output from the show ip route command in Example 6-4 displays that Router 1 is installing both links in its routing table.

Example 6-4 Example Output of Unequal-Cost Load Balancing in EIGRP

Router_1#show ip route 133.33.0.0
Routing entry for 133.33.0.0/16
Known via "eigrp 1", distance90, metric 2195456
Redistributing via eigrp 1
Advertised by eigrp 1 (self originated)
Last update from 10.1.1.2 on Serial1, 00:01:02 ago
Routing Descriptor Blocks:
* 192.168.6.2, from 192.168.6.2, 00:01:02 ago, via Serial0
Route metric is2195456, traffic share count is 5
Total delay is 21000 microseconds, minimum bandwidth is 1544 Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0
10.1.1.2, from 10.1.1.2, 00:01:02 ago, via Serial1
Route metric is10537472, traffic share count is 1
Total delay is 21000 microseconds, minimum bandwidth is 256Kbit
Reliability 255/255, minimum MTU 1500 bytes
Loading 1/255, Hops 0

In Example 6-4, the route through Serial 0 has a traffic share count of 5, compared to a traffic share count of 1 through Serial 1. This indicates that the router will send five packets over Serial 0 for every packet sent over Serial 1.

ability is broken at Layer 2, which further affects Layer 3 broadcast, and IGRP fails to work properly. The Layer 3 broadcast is further converted into a Layer 2 broadcast. If Layer 2 has problems in handling Layer 2 broadcasts, the IGRP updates will not be propagated across. The debug shows that the broadcast is being originated at one end but is not getting across.

Figure 5-11 shows the network diagram for a Frame Relay problem while running IGRP.

In Figure 5-11, Router 1 and Router 2 are connected by Frame Relay. (Although, this could be any Layer 2 medium—X.25, Ethernet, FDDI, and so forth.)

Figure 5-12 shows the flowchart to follow to solve this problem.

Debugs and Verification
Example 5-32 shows the output of debug ip packet detail 100, which verifies that R1 is sending and receiving IGRP updates without any problem. On R2, updates are being sent but are not received. This means that the IGRP update is being lost at Layer 2.

Example 5-32 debug ip packet detail 100 Command Output Shows That R1 Is Successfully Sending IGRP Updates

R1#show access-list 100
access-list 100 permit ip any host 255.255.255.255
R1#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R1#
IP: s=131.108.1.1 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9
IP: s=131.108.1.2 (Ethernet), d=255.255.255.255, len 46, rcvd 2, proto=9
_____________________________________________________________________________________
R2#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R2#
IP: s=131.108.1.2 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9
IP: s=131.108.1.2 (local), d=255.255.255.255 (Ethernet0), len 46, rcvd 2, proto=9

Solution
IGRP sends updates on a broadcast address of 255.255.255.255. If this address gets blocked at Layer 2, IGRP will not function properly. The root of the Layer 2 problem could result from a simple Ethernet switch, Frame Relay cloud, bridging cloud, and so on. Fixing the Layer 2 problem is beyond the scope of this book. We will leave this up to you, but here are some tips:

• In cases of Frame Relay
  • Check for the broadcast keyword missing in the frame-relay map statement.
  • Call your telco and make sure that it is propagating broadcast traffic across.
• In cases of a bridging cloud
  • Make sure that any bridge in the middle is not dropping the broadcast packets.
  • If the middle medium is Token Ring to Ethernet, make sure that the translational bridging is working properly.

Example 5-33 shows that after fixing the Layer 2 problem, IGRP routes get installed in the routing table.

Example 5-33 Verifying IGRP Routes Show Up in the Routing Table After Resolving the Layer 2 Problem

R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Ethernet0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Ethernet0
Route metric is 8976, 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 0

IGRP Routes Not in the Routing Table—Cause: Sender’s AS Mismatch

IGRP updates carry the AS number. When a receiver receives an IGRP update and the AS number of the sender does not match with its own AS number, IGRP ignores that update. As a result, no IGRP routes are installed in the routing table. Multiple IGRP processes can be run under different AS numbers. These processes are independent of each other.

Figure 5-13 shows the flowchart to follow to solve this problem.

Debugs and Verification
Example 5-34 shows the configuration of both R1 and R2. R1 is running IGRP AS 1, and R2 is running IGRP AS 2.

Example 5-34 R1 and R2 Configurations Show That They Are in Different Autonomous Systems

R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
router igrp 2
network 131.108.0.0
!
_____________________________________________________________________________________
R1#
interface Loopback0
ip address 131.108.2.1 255.255.255.0
!
interface Serial0
ip address 131.108.1.1 255.255.255.0
!
router igrp 1
network 131.108.0.0
!

Example 5-35 shows the output of debug ip igrp transaction and debug ip packet 100 detail on R1 and R2. Both routers are sending the IGRP update, but the update never reaches the other side. Both routers show that the IGRP packets are being received, but IGRP is ignoring these updates because of the AS number mismatch. Unfortunately, the debug does not show the mismatch message; however, it does show that IGRP is not displaying the update received message in the debugs.

Example 5-35 debug ip igrp transaction Command Output on R1 and R2 Reveals the Status of IGRP Updates

R1#show debug
Generic IP:
IP packet debugging is on (detailed)
IP routing:
IGRP protocol debugging is on
IGRP event debugging is on
R1#
R1#show access-list 100
access-list 100 permit ip any host 255.255.255.255
R1#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R1#
R1#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: sending update to 255.255.255.255 via Serial0 (131.108.1.1)
subnet 131.108.3.0, metric=501
IP: s=131.108.1.2 (Serial0), d=255.255.255.255, len 64, rcvd 2, proto=9
_____________________________________________________________________________________
R2#debug ip packet 100 detail
IP packet debugging is on (detailed) for access list 100
R2#
R2#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: sending update to 255.255.255.255 via Serial0 (131.108.1.2)
subnet 131.108.2.0, metric=501
IP: s=131.108.1.1 (Serial0), d=255.255.255.255, len 64, rcvd 2, proto=9

Solution
In this example, the sender is sending AS 1 in the update. When R2 receives it, it ignores this update because R2 is running IGRP under AS 2.

To fix this problem, change the IGRP configurations so that R1 and R2 both agree on one AS number.

Example 5-36 shows the new configuration on R2 that fixes this problem.

Example 5-36 Configuring R2 to Have the Same AS Number as R1

R2#
interface Loopback0
ip address 131.108.3.2 255.255.255.0
!
interface Serial0
ip address 131.108.1.2 255.255.255.0
!
no router igrp 2
!
router igrp 1
network 131.108.0.0
!

Example 5-37 shows that after fixing the AS problem, IGRP routes get installed in the routing table.

Example 5-37 show ip route Command Output Reveals That the AS Problem Preventing IGRP Route Installation Is Resolved

R2#show ip route 131.108.2.0
Routing entry for 131.108.2.0/24
Known via "igrp 1", distance 100, metric 8976
Redistributing via igrp 1
Advertised by igrp 1 (self originated)
Last update from 131.108.1.1 on Serial0, 00:00:12 ago
Routing Descriptor Blocks:
* 131.108.1.1, from 131.108.1.1, 00:00:12 ago, via Serial0
Route metric is 8976, 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 0

Problem: IGRP Is Not Installing All Possible Equal-Cost Paths—Cause: maximum-paths Restricts IGRP to a Maximum of Four Paths by Default

By default, Cisco routers support only four equal paths, for load-balancing purposes. The com-mand maximum-path can be used for up to six equal-cost paths. If the command is not configured properly, it can cause problems, as discussed in this section. The command maximum-path is incorrectly used, so it allows only one path to the destination even though more than one path exists. The maximum-path 1 command should be used only when load balancing is not desired.

Figure 5-14 shows the network setup that produces the problem of IGRP not installing all possible equal-cost paths.

Example 5-38 shows the routing table entry of Router R1. Only one route is being installed in the routing table.

Example 5-38 Routing Table for R1 in Figure 5-14

R1#show ip route igrp
131.108.0.0/24 is subnetted, 1 subnets
I 131.108.2.0 [100/8976] via 131.108.5.3, 00:00:09, Ethernet2

Figure 5-15 shows the flowchart to follow to solve this problem.

Debugs and Verification
Example 5-39 shows the output of the debug ip igrp transaction command on Router R1, revealing that Router R1 is receiving two equal-cost route paths.

Example 5-39 debug ip igrp transaction Command Output Reveals the Number of Equal-Cost Paths Received

R1#debug ip igrp transaction
IGRP protocol debugging is on
IGRP: received update from 131.108.5.3 on Ethernet2
network 137.99.0.0, metric 8976 (neighbor 501)
IGRP: received update from 131.108.1.2 on Ethernet1
network 137.99.0.0, metric 8976 (neighbor 501)

Only one route is installed in the routing table. You see only one route in the routing table instead of two because the operator has configured maximum-paths 1 in the configuration.

Example 5-40 shows the current configuration for Router R1. The maximum-path setting is set to 1, which prevents IGRP from installing more than one path in the routing table. By default, maximum-path is set to 4.

Example 5-40 Current R1 Configuration

router igrp 1
network 131.108.0.0
maximum-paths 1

Solution
By default, Cisco IOS Software allows up to four equal-cost routes to be installed into the routing table. This can be increased up to six routes if configured properly. If there is a desire to do a load balancing over six links, use this command.

Example 5-41 shows the configuration that installs six equal-cost route paths in the routing table.

Example 5-41 Configuring R1 to Accept Up to Six Equal-Cost Route Paths in the Routing Table

R1#router igrp 1
maximum-paths 6

This example makes more sense when you have more than four paths and only four are getting installed in the routing table. Because four equal-cost routes is a default, you must configure maximum-paths to accommodate the fifth and (possibly sixth) route.

Troubleshooting IGRP Routes Advertisement

All these problems discussed so far deal with a problem on the receiving end or a problem in the middle (Layer 2).

There is a third possibility for why the route is not being installed in the routing table—the problem is occurring on the sender’s end. The sender might be having a problem sending IGRP updates, so the receiver is not installing the IGRP routes in the routing table. This next section talks about the things that can go wrong on the sender’s side.

This section discusses the most common scenarios that can prevent IGRP routes from being advertised out. Some cases overlap with IGRP route installation problems—for example, missing network statements and downed interfaces. This section assumes that you did troubleshoot all the possible scenarios discussed in the previous section and that the prob-lems still exist. In this case, the last place to look at is the sender.

This chapter covers two problems related to IGRP route advertisement originating from the sender’s side:

• The sender is not advertising IGRP routes.
• The candidate default is not being advertised.

• Troubleshooting IP Routing Protocols