• Eigrp Default Metric
• Cisco Router Eigrp Redistribute Static
• Router Eigrp Redistribute Connected
• Router Eigrp 100 Redistribute Static
• Router Eigrp Redistribute Static Friction

EIGRP message authentication uses a key chain for storing authentication key. The key IDs and passwords must match on both routers Stub router can be configured to advertise connected, summary, static, redistributed or leaked routes Auto summarization feature summarizes routes along classful boundaries (global config). The problem is that, without inserting the redistribute static command under the router eigrp command in Router B, Router B automatically redistributes all the 127 static routes configured to Router A. This can cause unnecessary routes being advertised inadvertently throughout the entire network. Again, using “redistribution” loosely the EIGRP process doesn’t not redistribute the static route into it’s process. (The lack of advertisement occurs with a static route pointing to an interface AND a next hop, or just out a next hop). You can inject static routes into EIGRP two ways: The 'network' command 'redistribute static' You only need one or the other; here you've used both. It seems that the redistribution command takes precedence over the network command so the route is appearing as static routes. Remove 'redistribute static' and the route should appear as internal.

Troubleshooting EIGRP Route Advertisement

Sometimes, EIGRP has issues with route advertisement. This section discusses methods for troubleshooting EIGRP route advertisement problems, which can be categorized as follows:

• EIGRP is not advertising routes to neighbors when the network administrators think that it should.

• EIGRP is advertising routes to neighbors when the network administrators think that it shouldn't.

• EIGRP is advertising routes with a metric that is not understood by the network administrators.

EIGRP Is Not Advertising Routes to Neighbors When the Network Administrators Think That It Should

This section discusses methods for troubleshooting issues related to EIGRP not advertising routes to the neighbors. Figure 7-18 shows a flowchart documenting how to troubleshoot this issue.

Figure 7-18 Troubleshooting Flowchart for Problems Related to EIGRP Not Advertising Routes to Its Neighbors

EIGRP Is Not Advertising Routes to Its Neighbors—Cause: Distribute List

Figure 7-19 shows a network in which EIGRP is not advertising routes to its neighbor because of a distribute list problem. Example 7-14 shows the configurations for Routers A and B in this network.

Figure 7-19 EIGRP Network Not Advertising Routes to Its Neighbors Because of a Misconfigured Distribute List

Example 7-14 Configurations for Routers A and B in Figure 7-19

The problem is that Router A is not receiving the routes from Router B about network 192.168.3.16. Example 7-15 shows the debug output on Router B.

Example 7-15 debug ip eigrp Command Output on Router B

As the output in Example 7-15 reveals, Router B won't advertise the 192.168.3.16 because of the distribute list configuration. Looking again at the configuration in Example 7-14, you can see that the distribute list is tied to access-list 1, and access-list 1 has the network number misconfigured. access-list 1 should permit 192.168.3.16 instead of 192.168.3.160. Because 192.168.3.16 is not included in the permit statement, there is an implicit deny in the access list that prevents network 192.168.3.16 being advertised.

The solution to this problem is to change access-list 1 to permit 192.168.3.16 instead of 192.168.3.160. Changing the access list to permit 192.168.3.16 fixes the problem.

EIGRP Is Not Advertising Routes to Its Neighbors—Cause: Discontiguous Networks

Using the network diagram in Figure 7-19, another issue with EIGRP not advertising the network could be manual summarization configured on the interface or autosummarization across a major network boundary, as shown in Example 7-16.

Example 7-16 Configurations for Routers A and B in Figure 7-19

The problem is that Router A is not receiving routes for the 192.168.3.16 network from Router B. Example 7-17 shows the debug output on Router B.

Example 7-17 debug ip eigrp Command Output on Router B

From the debug, Router B shows that it is not advertising the 192.168.3.16/28 network; however, it is advertising only the major network of 192.168.3.0/24 to Router A. Looking at the configuration of Routers A and B in Example 7-16 shows that the two routers have a discontiguous network. Router A has the network of 192.168.3.32/28 in its Ethernet, while Router B has another network of 192.168.3.16/28 in its Ethernet, separated by a network of 10.1.1.0/24. Therefore, when Router B advertises the network of 192.168.3.16/28 across a major network boundary of 10.1.1.0, it advertises only the major network of 192.168.3.0/24 to Router A instead of advertising the network of 192.168.3.16/28. When Router A receives the major network of 192.168.3.0/24, it does not install the network in the topology table because it already has the 192.168.3.0 network on its Ethernet interface.

Two solutions to the discontiguous network problem exist. One is to configure the command no auto-summary under router eigrp. This command tells EIGRP not to autosummarize to major network boundaries. As a result, Router B's configuration will look like Example 7-18.

Example 7-18 Disabling Autosummarization on Router B to Prevent Discontiguous Networks

The second solution is to change the IP address of the serial interfaces on each side of the link to the 192.168.3.0 subnet. As an example, the serial IP address can take 192.168.3.65/28 and 192.168.3.66/28. This way, Router B won't autosummarize the route because it is not across a major network boundary.

EIGRP Is Not Advertising Routes to Neighbors—Cause: Split-Horizon Issues

EIGRP has its own split-horizon command. This command, configured under the inter-face, is shown here:

Turning off IP split horizon does not turn off EIGRP split horizon. Figure 7-20 shows an EIGRP network vulnerable to split-horizon issues.

Figure 7-20 EIGRP Network Susceptible to EIGRP Split-Horizon Problems

Example 7-19 shows the configurations for Routers A, B, and C in the hub-and-spoke network in Figure 7-20.

Example 7-19 Configurations for Routers A, B, and C in Figure 7-20

A common network environment, shown in Figure 7-20 is the Frame Relay hub-and-spoke design, in which the hub router (Router A) in Figure 7-20 doesn't have a subinterface configured for each remote spoke site. As a result, the hub router uses a main interface to connect to the two spoke sites. The problem is that Router B doesn't receive the routes for Router C's Ethernet network of 172.16.4.0/24, and Router C doesn't receive the routes for Router B's Ethernet net- work of 172.16.3.0/24. The problem seems to be at the hub site. The hub site sees all the routes, but the hub site is not passing the routes from Router B to Router C, and vice versa. Example 7-20 shows the debug output on the hub router (Router A).

Example 7-20 debug ip eigrp Command Output on Router A

From the debug, you can see that the hub router advertises only the 172.16.1.0/24 route on Serial0. The hub router receives routes for the 172.16.3.0/24 and 172.16.4.0/24 interfaces from Router B and Router C. The problem is that the hub router is not sending all the routes on Serial0. Referring to the configurations of Routers A, B, and C in Example 7-19, you can see that their serial interfaces are all in the same subnet, but they are not physically connected. Therefore, the hub router receives the routes from Serial0 from Router B and Router C but won't readvertise those routes on Serial0. This follows the split-horizon rule (route information must not exit the router interface through which that information was received).

To solve the split-horizon problem for EIGRP, the easiest fix is to turn off split horizon for EIGRP. Example 7-21 shows the correct configuration change to disable split horizon.

Eigrp Default Metric

Example 7-21 Disabling Split Horizon on the Hub Router

Example 7-22 shows the debug output on Router A after the configuration change.

Example 7-22 Verifying That Disabling Split Horizon Corrected the Problem

Now the spoke Routers B and C can see the routes. Another fix for the split-horizon problem is to configure subinterfaces on the hub router and assign different IP address subnets for each subinterface. Keep in mind that the support of a serial subinterface is valid for only the WAN PVC type of connection, such as ATM or Frame Relay. Example 7-23 shows the configuration for such a setup to avoid the EIGRP split-horizon problem.

Example 7-23 Configuring Subinterfaces with Different IP Address Subnets to Combat EIGRP Split-Horizon Problems

When subinterfaces are configured in Router A, this logically separates the connection to Router B and Router C. Each connection to Router B and Router C has its own network. For example, the connection from Router A to Router B is now through connection Serial 0.1 over the 172.16.2.0/24 network, and the connection from Router A to Router C is now through connection Serial 0.2 over the 172.l6.5.0/24 network. Because Router A has two logical connection to Routers B and C over two different logical interfaces, the split horizon rule doesn't apply and Router A will advertise all the routes to routers B and C, as shown in Example 7-24.

Example 7-24 Verifying That Configuring the Subinterface with Different Subnets Solves the Split-Horizon Problem

With Router A advertising all the routes to the remote Routers, Routers B and C now can reach each other's LAN interface.

EIGRP Is Advertising Routes to Neighbors When the Network Administrators Think That It Shouldn't

Sometimes, EIGRP advertises unexpected routes to its neighbors. See Figure 7–21 for a flowchart of troubleshooting EIGRP unexpected advertisement of routes.

Figure 7-21 Flowchart for Troubleshooting EIGRP Unexpected Advertisement of Routes

Refer to Figure 7-19 for the network diagram on this example. Example 7-25 shows the configurations for Routers A and B.

Example 7-25 Configuration of Router A and Router B for the Example Shown in Figure 7-19

The problem is that, without inserting the redistribute static command under the router eigrp command in Router B, Router B automatically redistributes all the 127 static routes configured to Router A. This can cause unnecessary routes being advertised inadvertently throughout the entire network. The cause of the problem is that the static routes are configured with the outbound interface. In this case, the router thinks that all the static routes are directly connected to the Ethernet 0 interface. These Ethernet interfaces also are covered under the router EIGRP process by the network 192.168.130.0 command. Because Ethernet 0 is considered to run EIGRP, all the networks connected to it by a static route also are considered to belong to the EIGRP process. The router then advertises all these static routes even though redistribute static is not configured.

Cisco Router Eigrp Redistribute Static

The solution to this problem is either to configure a distribute list that prevents the router from advertising all those static routes or to change the static routes to reference the next-hop IP addresses instead of an interface. This way, the router will not advertise all these static routes and flood the entire network with unnecessary routes.

Example 7-26 shows the distribute list configured on Router B to stop sending the unwanted redistributed static routes.

Example 7-26 Configuration on Router B to Stop Sending Unwanted Static Routes by Configuring Distribute List

The distribute list is tied to access-list 1, and access-list 1 denies sending out any routes that ranges from 192.168.0.0/24 through 192.168.127.0/24 and permits sending any other routes. Such a distribute list stops sending out the unwanted redistributed static routes in the example. The debug output on Router B, shown in Example 7-27, shows that the router does not send the static routes to other EIGRP neighbors because the distribute list is configured.

Example 7-27 Verification on Router B Not Sending Out Static Routes Because a Distribute List Is Configured

The other solution to this problem is to redefine the static routes so that the next hop of the static route is an IP address instead of an interface. Example 7-28 shows the change of static route configuration in Router B to fix the problem.

Example 7-28 Configuration on Router B to Stop Sending Unwanted Static Routes by Reconfiguring Static Routes with the Next Hop—an IP Address Instead of an Interface

EIGRP Is Advertising Routes with Unexpected Metric

Not only might EIGRP advertise unexpected routes to its neighbors, but it also might advertise an unexpected metric to its neighbors. The EIGRP metric is the basis of route selection done by EIGRP, which selects the route with the lowest EIGRP metric to the destination network. An unexpected EIGRP metric being sent or received on the router might alter route selection to the destination network. The end result might be suboptimal routing. Figure 7-22 shows the flowchart for troubleshooting such an issue.

Figure 7-22 Flowchart for Troubleshooting EIGRP Advertisement of Routes with Unexpected Metric Value

Router Eigrp Redistribute Connected

The case study that follows is a case of an offset list that is created inadvertently, causing the router to route packets in a suboptimal fashion. The offset-list command adds an offset value to the routing metrics. It's a way to manipulate the routing metric for certain routes, thereby, altering the route selection for a particular routing protocol. Figure 7-23 illustrates the network setup for the unexpected metric value problem.

Figure 7-23 EIGRP Network Susceptible to EIGRP Advertisement Problems Because of Unexpected Metric Values

Example 7-29 shows the configurations for the routers in the EIGRP network shown in Figure 7-23.

Example 7-29 Configurations for Routers A, B, and C in Figure 7-23

The problem is that Router A is not taking the direct paths to Router C to reach Router C's Ethernet network of 172.16.5.0/24. Instead, Router A takes the path to Router B and then to Router C. This takes an extra hop. Example 7-30 shows the routing table and the EIGRP topology table for 172.16.5.0 255.255.255.0 for Router A.

Example 7-30 show ip route and show ip eigrp topology Command Output Reveals the Routes That Router A Is Taking to Reach Router C's 172.16.5.0/24 Ethernet Network

Example 7-30 shows that Router A chooses Router B as the next hop to Router C because Router B has a better metric than Router C. Looking in detail at the topology table shows that the path to Router C has more delay than the path to Router B, but all the links are T1 links. The interface configuration in Router C didn't show any manually configured delay value. Looking at the configuration in Router C more in detail reveals the offset-list configuration under router eigrp in Router C.

The offset list in Router C adds a metric of 600,000 to outgoing routes in Serial1. This is the cause of the problem. The offset values added increase the delay value when Router C sends the routes to Router A, causing Router A to prefer routes from Router B.

The solution is to remove the offset list configured on Router C. To remove the offset list, configure Router C as in Example 7-31.

Example 7-31 Removing the Offset List from Router C's Configuration

Router Eigrp 100 Redistribute Static

Example 7-32 shows the routing table and the topology table in Router A after removing the offset list configured on Router C.

Example 7-32Å@show ip route and show ip eigrp topology Command Output Verifies That Router A Is Now Taking the Optimal Routes to Reach Router C's 172.16.5.0/24 Ethernet Network

Router Eigrp Redistribute Static Friction

The output in Example 7-32 now shows 172.16.3.2 as the next hop to Router C, which is the optimal path to the 172.16.5.0/24 network. Also, compare the topology table shown in Example 7-30 and Example 7-32. The EIGRP metric coming from the neighbor 172.16.3.2 has been reduced from the metric of 2,795,456 to 2,195,456. This reduction of metric of 600,000 is the result of removing the offset list. As this case study demonstrates, it is impor-tant that you scrutinize the configuration when abnormal behavior occurs. When opening a case with Cisco's TAC, be sure to provide router configuration whenever possible.