Configuring EIGRP


The case studies in this section demonstrate a basic EIGRP configuration and then examine summarization techniques and interoperability with IGRP.

Case Study: A Basic EIGRP Configuration

EIGRP requires only two steps to begin the routing process:

Step 1.

Enable EIGRP with the command router eigrp process-id.

Step 2.

Specify each major network on which to run EIGRP with the network command.

The process ID may be any number between 1 and 65535 (0 is not allowed), and it may be arbitrarily chosen by the network administrator, if it is the same for all EIGRP processes in all routers that must share information. Alternatively, the number might be a publicly assigned autonomous system number. Figure 7-31 shows a simple network; the configurations for the three routers are displayed in Example 7-14, Example 7-15, and Example 7-16.

Figure 7-31. Unlike IGRP, EIGRP will support the VLSM requirements of this network.


Example 7-14. Earhart.
router eigrp 15  network 172.20.0.0

Example 7-15. Cochran.
router eigrp 15  network 172.20.0.0  network 192.167.17.0

Example 7-16. Lindbergh.
router eigrp 15  network 172.20.0.0  network 192.167.16.0

Earhart's route table is shown in Example 7-17. The table shows that the default EIGRP administrative distance is 90 and that network 172.20.0.0 is variably subnetted.

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

The network of Figure 7-31 uses default metrics, unlike the earlier examples in this chapter, so a review of the EIGRP metric calculation in a more realistic scenario might be useful.

Tracing the route from Earhart to network 192.168.16.0, the path traverses a serial interface and an Ethernet interface, each with default metric values. The minimum bandwidth of the route will be that of the serial interface,[15] and the delay will be the sum of the two interface delays. Referring back to Table 7-1:

[15] Remember that the default bandwidth of a serial interface is 1544K.

BWEIGRP(min) = 256 x 6476 = 1657856

DLYEIGRP(sum) = 256 x (2000 + 100) = 537600

Therefore,

Metric = 1657856 + 537600 = 2195456

Case Study: Unequal-Cost Load Balancing

Given up to 16 parallel routes of equal cost,[16] EIGRP will do equal-cost load balancing under the same CEF/fast/process switching constraints as RIP. Unlike RIP, EIGRP can also perform unequal-cost load balancing. An additional serial link has been added between Earhart and Cochran in Figure 7-32, with a configured bandwidth of 256K. The goal is to have Earhart perform unequal-cost load balancing across these two linksspreading the traffic load inversely proportional to the metrics of the link.

[16] The default is four paths. See the case study on setting maximum paths for further details.

Figure 7-32. EIGRP can be configured to perform unequal-cost load balancing across links such as the two between Earhart and Cochran.


Examining the route from Earhart's S0.1 interface to network 192.168.17.0, the minimum bandwidth is 1544K (assuming Cochran's Ethernet interface is using the default 100000K bandwidth for Fast Ethernet). Referring to Table 7-1, DLYEIGRP(sum) for the serial interface and the Fast Ethernet interface is 256 x ( 2000 + 10 ) = 514560. BWEIGRP(min) is 256 x (107/1544) = 1657856, so the composite metric of the route is 514560 + 1657856) = 2172416.

The minimum bandwidth on the route via Earhart's S0.3 to 192.168.17.0 is 256K; DLYEIGRP(sum) is the same as on the first route. Therefore, the composite metric for this route is 256 x (107/256) + 514560 = 10514432. Without further configuration, EIGRP will simply select the path with the lowest metric cost. Example 7-18 shows that Earhart is using only the path via Serial 0.1, with a metric of 2172416.

Example 7-18. Earhart is using only the lowest-cost link to network 192.168.17.0. Additional configuration is needed to enable unequal-cost load balancing.
Earhart#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B  BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E  EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default, U - per-user static route, o  ODR        P - periodic downloaded static route Gateway of last resort is not set      172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks C       172.20.10.0/27 is directly connected, Ethernet0 C       172.20.15.4/30 is directly connected, Serial0.1 C       172.20.15.0/30 is directly connected, Serial0.2 C       172.20.15.8/30 is directly connected, Serial0.3 D    192.168.17.0/24 [90/2172416] via 172.20.15.6, 00:00:09, Serial0.1 D    192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:09, Serial0.2 Earhart#

The variance command is used to determine which routes are feasible for unequal-cost load sharing. Variance defines a multiplier by which a metric may differ, or vary, from the metric of the lowest-cost route. Any route whose metric exceeds the metric of the lowest-cost route, multiplied by the variance, will not be considered a feasible route.

The default variance is one, meaning that the metrics of multiple routes must be equal, to load balance. Variance must be specified in whole numbers.

The metric of Earhart's route through S0.3 is 10514432/2172416 = 4.8 times larger than the metric of the S0.1 route. So to conduct unequal-cost load balancing over both links, the variance at Earhart should be five. The EIGRP configuration is in Example 7-19.

Example 7-19. Earhart's configuration uses a variance of five to perform unequal-cost load sharing using EIGRP.
router eigrp 15  network 172.20.0.0  variance 5

After specifying a variance of five at Earhart, its route table will include the second, higher-cost route (Example 7-20). The following three conditions must be met for a route to be included in unequal-cost load sharing:

  • The maximum-paths limit must not be exceeded as a result of adding the route to a load-sharing "group."

  • The next-hop router must be metrically closer to the destination. That is, its metric for the route must be smaller than the local router's metric. A next-hop router, being closer to the destination, is often referred to as the downstream router.

  • The metric of the lowest-cost route, when multiplied by the variance, must be greater than the metric of the route to be added.

Example 7-20. The composite metric of the second path to 192.168.17.0 from Earhart is 10514432, or 4.8 times the metric of the lowest-cost route. EIGRP will enter the second path into the route table if the variance is set to at least five.
Earhart(config)#router eigrp 15 Earhart(config-router)#variance 5 Earhart(config-router)#^Z Earhart#clear ip route * Earhart#show ip route Gateway of last resort is not set      172.20.0.0/16 is variably subnetted, 4 subnets, 2 masks C       172.20.10.0/24 is directly connected, Ethernet0 C       172.20.15.4/30 is directly connected, Serial0.1 C       172.20.15.0/30 is directly connected, Serial0.2 C       172.20.15.8/30 is directly connected, Serial0.3 D    192.168.17.0/24 [90/2172416] via 172.20.15.6, 00:00:02, Serial0.1                      [90/10514432] via 172.20.15.10, 00:00:02, Serial0.3 D    192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:02, Serial0.2 Earhart#

The rules concerning per destination versus per packet load sharing, discussed in Chapter 3, "Static Routing," apply here as well. Load sharing is per destination if the packet is fast switched or CEF switched using the default CEF configuration, and per packet if process switching is used or if the CEF configuration was modified. Example 7-21 shows a debug output resulting from 20 ping packets being sent through Earhart; CEF and fast switching have been turned off with no ip cef and no ip route-cache, and the router is performing unequal-cost, per packet load balancing. For every five packets sent over the 1544K link (to next hop 172.20.15.6), one packet is sent over the 256K link (to next hop 172.20.15.10). This corresponds to the approximately five-to-one variance of the metrics of these two paths.

Example 7-21. Per packet load sharing is being performed, with one packet being sent over the high-cost link for every five packets sent over the low-cost link.
IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.1), g=172.20.15.6,     len 100, forward IP: s=172.20.15.2 (Serial 2), d=192.168.17.1 (Serial0.3), g=172.20.15.10,     len 100, forward Earhart#

If variance is set at one, EIGRP enters only the lowest-cost route to a destination into the route table. In some situations, howeverfor example, to decrease reconvergence time or aid in troubleshootingall feasible routes should be entered into the table, even though no load balancing should occur. All packets should use the lowest-cost route and switch to the next-best path only if the primary fails. There is an implicit default command (that is, it exists, but is not observed in the configuration file) of traffic-share balanced. To configure the router to only use the minimum-cost path even when multiple paths are shown in the route table, change this default to traffic-share min. If there are multiple minimum-cost paths and traffic-share min is configured, EIGRP will perform equal-cost load balancing.

Case Study: Setting Maximum Paths

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

Figure 7-33 shows three parallel paths of varying costs from Earhart to address 172.18.0.0. The network administrator wants to load balance over a maximum of only two of these routes while ensuring that if either of these paths should fail, the third route will replace it.

Figure 7-33. The maximum-paths and variance commands can be used together to configure load balancing over only two of the three links between Earhart and Johnson. If either link fails, the third will take its place.


The metrics from Earhart are

Via S0.4: 256 x (9765 + (2000 + 10)) = 3014400

Via S0.5: 256 x (19531 + (2000 + 10)) = 5514496

Via S0.6: 256 x (78125 + (2000 + 10)) = 20514560

The metric of the S0.6 route is 6.8 times as large as the lowest-cost metric, so the variance is seven.

Earhart's EIGRP configuration is displayed in Example 7-22.

Example 7-22. Earhart's configuration uses the variance command and the maximum-paths command to provide unequal-cost load sharing over a specified maximum number of paths.
router eigrp 15  variance 7  network 172.20.0.0  maximum-paths 2

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

Example 7-23. The route table for Earhart, before and after the failure of one of three links, shows the results of using the variance and maximum-paths commands to configure load sharing to 172.18.0.0.
Earhart#debug eigrp neighbor EIGRP Neighbors debugging is on Earhart#show ip route Gateway of last resort is not set D    172.18.0.0/16 [90/5514496] via 172.20.15.18, 00:00:16, Serial0.5                    [90/3014400] via 172.20.15.14, 00:00:16, Serial0.4      172.20.0.0/16 is variably subnetted, 7 subnets, 2 masks C       172.20.15.20/30 is directly connected, Serial0.6 C       172.20.15.16/30 is directly connected, Serial0.5 C       172.20.10.0/24 is directly connected, Ethernet0 C       172.20.15.4/30 is directly connected, Serial0.1 C       172.20.15.0/30 is directly connected, Serial0.2 C       172.20.15.12/30 is directly connected, Serial0.4 C       172.20.15.8/30 is directly connected, Serial0.3 D    192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:18, Serial0.1                      [90/10537472] via 172.20.15.10, 00:00:18, Serial0.3 D    192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:19, Serial0.2 Earhart# 1w6d: EIGRP: Holdtime expired 1w6d: EIGRP: Neighbor 172.20.15.14 went down on Serial0.4 Earhart#show ip route Gateway of last resort is not set D    172.18.0.0/16 [90/5514496] via 172.20.15.18, 00:00:09, Serial0.5                    [90/20514560] via 172.20.15.22, 00:00:09, Serial0.6      172.20.0.0/16 is variably subnetted, 7 subnets, 2 masks C       172.20.15.20/30 is directly connected, Serial0.6 C       172.20.15.16/30 is directly connected, Serial0.5 C       172.20.10.0/24 is directly connected, Ethernet0 C       172.20.15.4/30 is directly connected, Serial0.1 C       172.20.15.0/30 is directly connected, Serial0.2 C       172.20.15.12/30 is directly connected, Serial0.4 C       172.20.15.8/30 is directly connected, Serial0.3 D    192.168.17.0/24 [90/2195456] via 172.20.15.6, 00:00:26, Serial0.1                      [90/10537472] via 172.20.15.10, 00:00:26, Serial0.3 D    192.168.16.0/24 [90/2195456] via 172.20.15.2, 00:00:26, Serial0.2 Earhart#

Care should be taken when configuring multiple parallel paths in a network. Too many parallel paths can increase the amount of time it takes for EIGRP to converge when a link fails, because the number of neighboring routers has increased, therefore increasing the querying scope.

Case Study: Multiple EIGRP Processes

Two new routers, Bleriot and Post, have been added to the network. A decision has been made to create two EIGRP process domains in the network with no communications between the two. Figure 7-34 shows the two autonomous systems and the related links for each.

Figure 7-34. The routers Bleriot and Cochran will each run multiple EIGRP processes to facilitate the creation of separate autonomous systems (AS 10 and AS 15) within this IGP.


The configurations for Post, Johnson, Lindbergh, and Earhart are straightforward: Johnson, Earhart, and Lindbergh will run EIGRP 15, and Post will run EIGRP 10. At Bleriot, the configuration will be as displayed in Example 7-24.

Example 7-24. Bleriot's configuration for EIGRP 15 and EIGRP 10.
router eigrp 15  network 172.20.0.0 ! router eigrp 10  network 10.0.0.0

Each process will run only on the interfaces of the networks specified. At Cochran, all interfaces other then FA0/0 belong to network 172.20.0.0 (see Example 7-25).

Using the passive-interface command prevents EIGRP Hellos from being sent on data links where they don't belong. Note that because Cochran's interfaces are in network 172.20.0.0, the passive-interface command is used to restrict unnecessary routing protocol traffic. For EIGRP, this command blocks unnecessary Hellos. No adjacencies will be formed; therefore, no other EIGRP traffic will be sent.

Example 7-25. Cochran's EIGRP 15 and EIGRP 10 configuration requires passive interfaces because the same major network number is used on both of Cochran's connected interfaces.
router eigrp 15  passive-interface Fastethernet0/1  network 172.20.0.0 ! router eigrp 10  passive-interface Serial0/0.1  passive-interface Serial 0/0.2  network 172.20.0.0

Bleriot's neighbor table (Example 7-26) shows that there is one neighbor for EIGRP process 10, 10.108.16.2, and one neighbor for process 15, 172.20.33.1.

Example 7-26. The neighbors associated with each of the multiple EIGRP processes are displayed using the show ip eigrp neighbor command.
Bleriot#show ip eigrp neighbors IP-EIGRP neighbors for process 15 H   Address                 Interface   Hold Uptime    SRTT   RTO   Q   Seq                                         (sec)          (ms)        Cnt  Num 0   172.20.33.1             Fa0/0         11 00:31:19    34   204   0   44 IP-EIGRP neighbors for process 10 H   Address                 Interface   Hold Uptime    SRTT   RTO   Q   Seq                                         (sec)          (ms)        Cnt  Num 0   10.108.16.2             Fa0/1         10 00:19:21   289  1734   0   6 Bleriot#

In lieu of passive interfaces, the network statement for EIGRP can be configured with wildcard bits. The wildcard bits specify which bits of the address are to be used when identifying interfaces to include in the EIGRP process.

Cochran's configuration is modified to that shown in Example 7-27.

Example 7-27. Cochran's EIGRP 15 and EIGRP 10 configuration uses wildcard bits with the network to narrow down the interfaces that will run EIGRP for a given process.
router eigrp 15  network 172.20.15.0 0.0.0.255 ! router eigrp 10  network 172.20.32.0 0.0.0.255

Cochran's configuration in Example 7-27 specifies that interfaces with addresses with the first three octets equal to 172.20.15 run EIGRP process 15, and interfaces with the first three octets equal to 172.20.32 run EIGRP process 10.

Case Study: Disabling Automatic Summarization

By default, EIGRP summarizes at network boundaries as do the protocols covered in previous chapters. Unlike those protocols, however, EIGRP's automatic summarization can be disabled.

Look at Bleriot's route table in Example 7-28. Notice that the entry for address 172.20.32.0 is known via Fast Ethernet 0/0, even though that path goes through one Fast Ethernet link and one serial link, from Bleriot, through Earhart to Cochran. The path via Post, attached to Fast Ethernet 0/1, is only one Fast Ethernet hop away. Look more closely at the route table, and you'll see the only entry for an address other then 10.108.16.0 known via Fast Ethernet 0/1 is 172.20.0.0/16. Post has summarized the 172.20.32.0 address before it advertises it to Bleriot over the 10.0.0.0 network boundary. To enable Bleriot to forward traffic to 172.20.32.0 via Post, disable automatic summarization on Post using the command no auto-summary.

Example 7-28. EIGRP automatic summarization can cause, in some cases, sub-optimal route choices.
Bleriot#show ip route Gateway of last resort is not set D    172.18.0.0/16 [90/3016960] via 172.20.33.1, 00:26:42, FastEthernet0/0      172.20.0.0/16 is variably subnetted, 10 subnets, 4 masks D       172.20.32.0/24 [90/2174976] via 172.20.33.1, 00:14:46, FastEthernet0/0 C       172.20.33.0/24 is directly connected, FastEthernet0/0 D       172.20.15.20/30            [90/20514560] via 172.20.33.1, 00:20:28, FastEthernet0/0 D       172.20.15.16/30            [90/5514496] via 172.20.33.1, 00:20:28, FastEthernet0/0 D       172.20.10.0/27 [90/284160] via 172.20.33.1, 00:43:34, FastEthernet0/0 D       172.20.15.4/30 [90/2172416] via 172.20.33.1, 00:26:59, FastEthernet0/0 D       172.20.15.0/30 [90/2172416] via 172.20.33.1, 00:27:18, FastEthernet0/0 D       172.20.0.0/16 [90/284160] via 10.108.16.2, 00:14:50, FastEthernet0/1 D       172.20.15.12/30            [90/3014400] via 172.20.33.1, 00:26:49, FastEthernet0/0 D       172.20.15.8/30            [90/10514432] via 172.20.33.1, 00:20:47, FastEthernet0/0      10.0.0.0/24 is subnetted, 1 subnets C       10.108.16.0 is directly connected, FastEthernet0/1 D    192.168.16.0/24 [90/2198017] via 172.20.33.1, 00:27:33, FastEthernet0/0 D    192.168.17.0/24 [90/2174976] via 172.20.33.1, 00:00:38, FastEthernet0/0 Bleriot#

Post's configuration is displayed in Example 7-29.

Example 7-29. Post's configuration disables automatic summarization for EIGRP.
router eigrp 10  network 10.0.0.0  network 172.20.0.0  no auto-summary

Bleriot's new route table is shown in Example 7-30.

Example 7-30. After disabling EIGRP automatic summarization, subnets of distant addresses can be seen in the route tables.
Bleriot#show ip route Gateway of last resort is not set D    172.18.0.0/16 [90/3016960] via 172.20.33.1, 00:35:27, FastEthernet0/0      172.20.0.0/16 is variably subnetted, 9 subnets, 3 masks D       172.20.32.0/24 [90/284160] via 10.108.16.2, 00:00:55, FastEthernet0/1 C       172.20.33.0/24 is directly connected, FastEthernet0/0 D       172.20.15.20/30            [90/20514560] via 172.20.33.1, 00:29:13, FastEthernet0/0 D       172.20.15.16/30            [90/5514496] via 172.20.33.1, 00:29:13, FastEthernet0/0 D       172.20.10.0/27 [90/284160] via 172.20.33.1, 00:52:19, FastEthernet0/0 D       172.20.15.4/30 [90/2172416] via 172.20.33.1, 00:35:44, FastEthernet0/0 D       172.20.15.0/30 [90/2172416] via 172.20.33.1, 00:36:03, FastEthernet0/0 D       172.20.15.12/30            [90/3014400] via 172.20.33.1, 00:35:34, FastEthernet0/0 D       172.20.15.8/30            [90/10514432] via 172.20.33.1, 00:29:20, FastEthernet0/0      10.0.0.0/24 is subnetted, 1 subnets C       10.108.16.0 is directly connected, FastEthernet0/1 D    192.168.16.0/24 [90/2198016] via 172.20.33.1, 00:36:06, FastEthernet0/0 D    192.168.17.0/24 [90/2174976] via 172.20.33.1, 00:00:38, FastEthernet0/0 Bleriot#

Figure 7-35 shows another situation in which disabling summarization is useful.

Figure 7-35. Disabling automatic summarization at Cochran and Lindbergh prevents ambiguous routing to network 192.168.18.0.


New Ethernet links have been added to routers Cochran and Lindbergh, and their addresses create a discontiguous subnet. The default behavior of both routers is to see themselves as border routers between major networks 172.20.0.0 and 192.168.18.0. As a result, Earhart will receive summary advertisements to 192.168.18.0 on its serial interfaces to both Lindbergh and Cochran. The result is an ambiguous routing situation in which Earhart records two equal-cost paths to 192.168.18.0; a packet destined for one of the subnets might or might not be routed to the correct link.

After disabling automatic summarization, Lindbergh's configuration will be as in Example 7-31.

Example 7-31. Lindbergh's configuration disables automatic summarization.
router eigrp 15  network 172.20.0.0  network 192.168.16.0  network 192.168.18.0  no auto-summary

By turning off summarization at Lindbergh and Cochran, the individual subnets 192.168.18.24/29 and 192.168.18.128/25 will be advertised into network 172.20.0.0, eliminating the ambiguities at Earhart.

Case Study: Stub Routing

Recall the discussion of DUAL earlier in this chapter. When an entry in a router's EIGRP topology table changes for the worse (either the metric increases, or the successor is no longer accessible), if there is no feasible successor for the address, the entry goes into Active state, and the router sends query packets to all its neighbors. If Earhart's link to Yeager, in Figure 7-36, goes down, Earhart sends queries to all its neighbors, including Johnson and Lindbergh, to find out if any neighbors have a path to Yeager. Earhart cannot modify its active entries in the topology table until it hears responses from all its queries regarding that entry. If a problem develops on the link to Lindbergh before Earhart has received a response to the query it sent about Yeager's addresses, Yeager's addresses will remain Active, even if the link between Earhart and Yeager comes back up.

Figure 7-36. Yeager is added to the network with a single link to Earhart.


Johnson and Lindbergh, in Figure 7-36, do not have back-door routes to any other site in the network. They are spoke routers in a hub-and-spoke design. The routers are not used to provide transit paths to any addresses in the network. When Lindbergh or Johnson need to forward a packet to an address that is not local to its site, the packet is forwarded to Earhart. Lindbergh knows of one path to 172.20.10.0, for instance, and that path is via Earhart. There is no need to send Johnson queries about addresses in other locations of the network and risk causing network instabilities. Johnson and Lindbergh can be configured with stub routing.

A router that has EIGRP Stub neighbors will not send queries to the stubs, thereby eliminating the chance that a stub-configured remote site will cause stuck in active conditions, and routing instabilities in other parts of the network.

Johnson is configured as an EIGRP stub router. Johnson's stub router configuration is displayed in Example 7-32.

Example 7-32. Johnson's EIGRP stub router configuration.
router eigrp 15  eigrp stub

No configuration changes are required on Earhart, the hub router.

The command eigrp stub causes Johnson to send updates containing its connected and summary routes only. Johnson can be configured to include any combination of connected routes, summary routes, static routes, or routes that have been redistributed into EIGRP, with the command:

eigrp stub {connected | redistributed | static | summary | receive-only}

Johnson can also be configured to not send any route information in updates, with the receive-only option. With the receive-only option, the remote router will not include any addresses in an update. Addresses connected to the Johnson router would have to be advertised to the rest of the network in some other way to ensure that traffic can reach the site, perhaps with static routes configured on Earhart.

To verify a neighbor is configured as a stub router, use the command show ip eigrp neighbor detail on the hub router, as shown in Example 7-33. Earhart's output shows that Johnson is configured as a stub.

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

Earhart has three stub neighbors. They are connected to the three links to Johnson: 172.20.15.22, 172.20.15.14, and 172.20.15.17.

Now, suppose a new link is added between Lindbergh and Cochran to add redundancy for traffic connected to Lindbergh's LAN traveling into the core of the network, as shown in Figure 7-37. Before Lindbergh is configured as a stub, when the links between Cochran and Earhart fail, Cochran will send queries to Lindbergh regarding alternate paths to the addresses in its topology table, 172.20.10.0 for instance. Lindbergh responds with a positive reply, because Lindbergh has an entry in its topology table for 172.20.10.0 via Earhart. Traffic from Cochran to 172.20.10.1 travels via Lindbergh.

Figure 7-37. A new link is added between Lindbergh and Cochran to add redundancy for traffic connected to Lindbergh's LAN traveling into the core of the network.


Although this is an alternate path, forwarding traffic through a remote site is not always desirable. In this case, Lindbergh's links are there to allow redundancy from Lindbergh's addresses to core addresses, not to enable Lindbergh to act as a transit router. The bandwidth might not be sufficient to provide transit routing. Stub routing easily solves this problem. As a stub, no queries are sent to Lindbergh, so Lindbergh will not make itself available to Cochran as an alternate path. Furthermore, Lindbergh only sends updates containing connected, summary, static, or redistributed routes, not remote routes, such as 172.20.10.0.

Example 7-34 shows Cochran's EIGRP neighbors when Lindbergh (connected to Serial 0/0.4) is not configured as a stub router. Cochran's two links to Earhart are brought down. Cochran's subsequent topology table (Example 7-35) shows all addresses are accessible via Lindbergh (Serial 0/0.4).

Example 7-34. Cochran's EIGRP neighbor table shows its neighbors. Lindbergh is not a stub.
Cochran#show ip eigrp neighbor detail IP-EIGRP neighbors for process 15 H   Address                 Interface       Hold Uptime    SRTT   RTO   Q   Seq                                             (sec)          (ms)        Cnt  Num 2   172.20.15.26            Se0/0.4           10 00:00:18  1152  5000   0   34    Version 12.3/1.2, Retrans: 0, Retries: 0 1   172.20.15.9             Se0/0.2           14 00:41:58   104   624   0   205    Version 12.1/1.2, Retrans: 1, Retries: 0 0   172.20.15.5             Se0/0.1           11 00:49:12    99   594   0   206    Version 12.1/1.2, Retrans: 2, Retries: 0 IP-EIGRP neighbors for process 10 H   Address                 Interface       Hold Uptime    SRTT   RTO   Q   Seq                                             (sec)          (ms)        Cnt  Num 0   172.20.32.2             Fa0/1             13 00:42:01    60   360   0   14    Version 12.1/1.2, Retrans: 2, Retries: 0 Cochran#

Example 7-35. After failure of the primary links between Cochran and Earhart, all addresses are accessible via the dual connected spoke router, Lindbergh.
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.5 (Serial0/0.1) is down: interface down %DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.9 (Serial0/0.2) is down: interface down Cochran#show ip eigrp topology IP-EIGRP Topology Table for AS(15)/ID(192.168.17.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 2707456         via 172.20.15.26 (2707456/2195456), Serial0/0.4 P 192.168.18.24/29, 1 successors, FD is 2195456         via 172.20.15.26 (2195456/281600), Serial0/0.4 P 192.168.16.0/24, 1 successors, FD is 2195456         via 172.20.15.26 (2195456/281600), Serial0/0.4 P 192.168.17.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/0 P 172.20.32.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/1 P 172.20.33.0/24, 1 successors, FD is 2707456         via 172.20.15.26 (2707456/2195456), Serial0/0.4 P 172.20.15.20/30, 1 successors, FD is 21536000         via 172.20.15.26 (21536000/21024000), Serial0/0.4 P 172.20.15.16/30, 1 successors, FD is 6535936         via 172.20.15.26 (6535936/6023936), Serial0/0.4 P 172.20.15.24/30, 1 successors, FD is 2169856         via Connected, Serial0/0.4 P 172.20.10.0/27, 1 successors, FD is 2707456         via 172.20.15.26 (2707456/2195456), Serial0/0.4 P 172.20.15.4/30, 1 successors, FD is 3193856         via 172.20.15.26 (3193856/2681856), Serial0/0.4 P 172.20.15.0/30, 1 successors, FD is 2681856         via 172.20.15.26 (2681856/2169856), Serial0/0.4 P 172.20.15.12/30, 1 successors, FD is 4035840         via 172.20.15.26 (4035840/3523840), Serial0/0.4 P 172.18.0.0/16, 1 successors, FD is 4038400         via 172.20.15.26 (4038400/3526400), Serial0/0.4 P 172.20.15.8/30, 1 successors, FD is 11535872         via 172.20.15.26 (11535872/11023872), Serial0/0.4 P 192.168.18.128/25, 1 successors, FD is 28160         via Connected, FastEthernet0/2 P 10.108.16.0/24, 1 successors, FD is 284160         via 172.20.32.2 (284160/281600), FastEthernet0/1 P 172.20.15.24/30, 1 successors, FD is 2169856         via Connected, Serial0/0.4 Cochran#

Now, Lindbergh is configured as an EIGRP stub in Example 7-36.

Example 7-36. Lindbergh is configured as an EIGRP stub router.
router eigrp 15  eigrp stub

Example 7-37 shows Cochran's EIGRP neighbor table, and Example 7-38 shows Cochran's EIGRP topology table after the same two links to Earhart fail again.

Example 7-37. Cochran's EIGRP neighbor table shows its neighbors. Lindbergh is a stub. Cochran is running a later IOS release (12.3) then Earhart. Notice that the fact that queries are suppressed is explicitly stated.
Cochran#show ip eigrp neighbor detail IP-EIGRP neighbors for process 15 H   Address                 Interface       Hold Uptime    SRTT   RTO   Q   Seq                                             (sec)          (ms)        Cnt  Num 2   172.20.15.26            Se0/0.4           10 00:01:08    56   336   0   20    Version 12.3/1.2, Retrans: 2, Retries: 0    Stub Peer Advertising ( CONNECTED SUMMARY ) Routes    Suppressing queries 1   172.20.15.9             Se0/0.2           11 00:29:46    96    576  0   111    Version 12.1/1.2, Retrans: 1, Retries: 0 0   172.20.15.5             Se0/0.1           10 00:37:00    96    576  0   110    Version 12.1/1.2, Retrans: 2, Retries: 0 IP-EIGRP neighbors for process 10 H   Address                 Interface       Hold Uptime    SRTT   RTO   Q   Seq                                             (sec)          (ms)        Cnt  Num 0   172.20.32.2             Fa0/1             13 00:29:50    51   306   0   10    Version 12.1/1.2, Retrans: 2, Retries: 0 Cochran#

Example 7-38. After failure of the primary links between Cochran and Earhart, only addresses connected to Lindbergh are reachable via Serial 0/0.4.
%DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.5 (Serial0/0.1) is down: interface down %DUAL-5-NBRCHANGE: IP-EIGRP(0) 15: Neighbor 172.20.15.9 (Serial0/0.2) is down: interface down Cochran#show ip eigrp topology IP-EIGRP Topology Table for AS(15)/ID(192.168.17.1) Codes: P - Passive, A - Active, U - Update, Q - Query, R - Reply,        r - reply Status, s - sia Status P 192.168.18.24/29, 1 successors, FD is 2195456         via 172.20.15.26 (2195456/281600), Serial0/0.4 P 192.168.16.0/24, 1 successors, FD is 2195456         via 172.20.15.26 (2195456/281600), Serial0/0.4 P 192.168.17.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/0 P 172.20.32.0/24, 1 successors, FD is 28160         via Connected, FastEthernet0/1 P 172.20.15.24/30, 1 successors, FD is 2169856         via Connected, Serial0/0.4 P 172.20.15.0/30, 1 successors, FD is 2681856         via 172.20.15.26 (2681856/2169856), Serial0/0.4 P 192.168.18.128/25, 1 successors, FD is 28160         via Connected, FastEthernet0/2 P 10.108.16.0/24, 1 successors, FD is 284160         via 172.20.32.2 (284160/281600), FastEthernet0/1 P 172.20.15.24/30, 1 successors, FD is 2169856         via Connected, Serial0/0.4 Cochran#

Configuring Lindbergh as an EIGRP stub prevents it from becoming a transit router during a failure of core links.

Configuring stub routing with EIGRP greatly increases the scalability of an EIGRP network, by minimizing queries, and thus the amount of time that network outages require addresses to be in an active state.

Stub routing eliminates queries sent to the stub router, but it does nothing to hide the topology of the rest of the network from the stub's point of view. Earhart can hide the topology of the rest of the network from the stubs. They don't need to know about every individual subnet because all packets for each of the subnets are always forwarded to the hub. Earhart can accomplish this by summarizing addresses.

Case Study: Address Summarization

Router Yeager, shown in the network in Figure 7-37, has a single link to Earhart. The six addresses that Earhart must advertise to Yeager can be summarized with two aggregate addresses. Earhart's configuration will be as shown in Example 7-39.

Example 7-39. Earhart's configuration summarizes routes to Yeager.
interface Ethernet2  ip address 10.15.15.254 255.255.255.252  ip summary-address eigrp 15 172.0.0.0 255.0.0.0  ip summary-address eigrp 15 192.168.16.0 255.255.240.0

The ip summary-address eigrp command will automatically suppress the advertisement of the more specific networks to Yeager. Example 7-40 shows the route table of Yeager before and after the aggregate addresses are configured. Even in this small network, the number of EIGRP-learned entries has been reduced by half; in a large network, the impact on route tables and the memory required to store them can be significant.

Example 7-40. Yeager's route table before and after aggregate addresses are configured at Earhart.
Yeager#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default, U - per-user static route, o - ODR        P - periodic downloaded static route Gateway of last resort is not set D    172.18.0.0/16 [90/3040000] via 10.15.15.254, 00:13:07, Ethernet0 D    172.20.0.0/16 [90/307200] via 10.15.15.254, 00:13:07, Ethernet0      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C       10.10.1.0/24 is directly connected, Ethernet1 C       10.15.15.252/30 is directly connected, Ethernet0      192.168.17.0/27 is subnetted, 1 subnets D       192.168.17.0 [90/2198016] via 10.15.15.254, 00:03:57, Ethernet0 D    192.168.16.0/24 [90/2221056] via 10.15.15.254, 00:01:51, Ethernet0      192.168.18.0/24 is variably subnetted, 2 subnets, 2 masks D       192.168.18.24/29 [90/2221056] via 10.15.15.254, 00:13:09, Ethernet0 D       192.168.18.128/25 [90/2198016] via 10.15.15.254, 00:13:09, Ethernet0 Yeager#show ip route Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area        * - candidate default, U - per-user static route, o - ODR        P - periodic downloaded static route Gateway of last resort is not set      10.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C       10.10.1.0/24 is directly connected, Ethernet1 C       10.15.15.252/30 is directly connected, Ethernet0 D    172.0.0.0/8 [90/307200] via 10.15.15.254, 00:00:57, Ethernet0 D    192.168.16.0/20 [90/2198016] via 10.15.15.254, 00:00:57, Ethernet0

Authentication

MD5 cryptographic checksums are the only authentication supported in EIGRP, which on first consideration might seem less flexible than RIPv2 and OSPF, which support both MD5 and clear-text passwords. However, clear-text password authentication should be used only when a neighboring device does not support the more secure MD5. Because EIGRP will be spoken only between two Cisco devices, this situation will never arise.

The steps for configuring EIGRP authentication are

Step 1.

Define a key chain with a name.

Step 2.

Define the key or keys on the key chain.

Step 3.

Enable authentication on an interface and specify the key chain to be used.

Step 4.

Optionally configure key management.

Key-chain configuration and management are described in Chapter 6. EIGRP authentication is enabled and linked to a key chain on an interface with the commands ip authentication key-chain eigrp and ip authentication mode eigrp md5.[17]

[17] Although MD5 is the only authentication mode available, the ip authentication mode eigrp md5 command anticipates the possibility of another mode being available in the future.

Referring to Figure 7-37, the configuration in Example 7-41 enables EIGRP authentication on Cochran's interface to Earhart.

Example 7-41. Cochran is configured to use MD5 authentication with Earhart.
key chain Edwards  key 1  key-string PanchoBarnes ! interface Serial0/0.1  ip address 172.20.15.6 255.255.255.252  ip authentication key-chain eigrp 15 Edwards  ip authentication mode eigrp 15 md5 interface Serial0/0.2  ip address 172.20.15.10 255.255.255.252  ip authentication key-chain eigrp 15 Edwards  ip authentication mode eigrp 15 md5

A similar configuration would be necessary on Earhart. The commands accept-lifetime and send-lifetime are used for key-chain management as described in Chapter 6.




CCIE Professional Development Routing TCP/IP (Vol. 12005)
Routing TCP/IP, Volume 1 (2nd Edition)
ISBN: 1587052024
EAN: 2147483647
Year: 2005
Pages: 233

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net