This chapter is from the book
This chapter is from the book
This chapter is from the book
Using EIGRP in an Enterprise Network
EIGRP is a scalable routing protocol that ensures that as a network grows larger, it operates efficiently and adjusts rapidly to changes. This section describes practical EIGRP-specific design and configuration techniques to implement an effective, scalable enterprise network.
EIGRP Scalability
The following are some of the many variables that affect network scalability:
- The amount of information exchanged between neighbors—If more information than necessary for routing to function correctly is exchanged between EIGRP neighbors, unnecessary work during routing startup and topology changes results.
- Number of routers—When a topology change occurs, the amount of resources consumed by EIGRP is directly related to the number of routers that must be involved in the change.
The topology's depth—The topology's depth can affect the convergence time. Depth refers to the number of hops that information must travel to reach all routers. For example, a multinational network without route summarization has a large depth and therefore increased convergence time.
A three-tiered network design (as described in Chapter 1, "Network Architecture Framework and Design Models") is highly recommended for all IP routing environments. There should never be more than seven hops between any two routing devices on an enterprise internetwork. The propagation delay and the query process across multiple hops when changes occur can slow down the convergence of the network when routes are lost.
- The number of alternative paths through the network—A network should provide alternative paths to avoid single points of failure. However, too many alternative paths can create problems with EIGRP convergence, because the EIGRP routing process, using queries, needs to explore all possible paths for lost routes. This complexity creates an ideal condition for a router to become stuck-in-active (described in the later "EIGRP Queries and Stuck-in-Active" section) as it awaits a response to queries that are being propagated through these many alternative paths.
For proper EIGRP operation, you should follow some common design principles. For example, routers located at convergence points within the network need sufficient memory to buffer a large number of packets and to support numerous processes related to routing large volumes of traffic.
On WAN links, and especially with the hub-and-spoke topology, enough bandwidth should be provided to prevent router overhead traffic from interfering with normal user-generated traffic. In this respect, the impact of EIGRP packets being lost because of contention for bandwidth might be greater than application delays experienced by some users.
EIGRP Route Summarization
Route summarization is most effective with a sound address allocation. Having a two- or three-layer hierarchical network design, with routers positioned by function rather than by geography, greatly assists traffic flow and route distribution.
Figure 3-27 shows the topology of a nonscalable internetwork in which addresses (subnets) are either randomly assigned or assigned by historical requirements. In this example, multiple subnets from different major networks are located in each cloud, requiring many subnet routes to be injected into the core. In addition, because of the random assignment of addresses, query traffic cannot be localized to any portion of the network, thus increasing convergence time. Administration and troubleshooting are also more complex in this scenario.
)
Figure 3-27 Nonscalable Internetwork
Figure 3-28 illustrates a better-designed network. Subnet addresses from individual major networks are localized within each cloud. This allows summary routes to be injected into the core. As an added benefit, the summary routes act as a boundary for the queries generated by a topology change.
)
Figure 3-28 Scalable Internetwork
EIGRP Queries and Stuck-in-Active
As an advanced distance vector routing protocol, EIGRP relies on its neighbors to provide routing information. If a route is lost and no FS is available, EIGRP queries its neighbors about the lost route.
Recall that when a router loses a route and does not have an FS in its topology table, it looks for an alternative path to the destination. This is known as going active on a route. (A route is considered passive when a router is not recomputing that route.) Recomputing a route involves sending query packets to all neighbors on interfaces other than the one used to reach the previous successor (split horizon), inquiring whether they have a route to the given destination. If a router has an alternative route, it answers the query with a reply packet and does not propagate the query further; the reply includes the alternate route. If a neighbor does not have an alternative route, it queries each of its own neighbors for an alternative path. The queries then propagate through the network, thus creating an expanding tree of queries. When a router answers a query, it stops the spread of the query through that branch of the network; however, the query can still spread through other portions of the network as other routers attempt to find alternative paths, which might not exist.
Because of the reliable multicast approach used by EIGRP when searching for an alternative to a lost route, it is imperative that a reply be received for each query generated in the network. In other words, when a route goes active and queries are initiated, the only way this route can come out of the active state and transition to passive state is by receiving a reply for every generated query.
When a route goes to SIA state, the router resets the neighbor relationships for the neighbors that failed to reply. This causes the router to recompute all routes known through that neighbor and to re-advertise all the routes it knows about to that neighbor.
The most common reasons for SIA routes are as follows:
- The router is too busy to answer the query—generally as a result of high CPU usage or memory problems—and cannot allocate memory to process the query or build the reply packet.
- The link between the two routers is not good, so some packets are lost between the routers. The router receives an adequate number of packets to maintain the neighbor relationship, but the router does not receive all queries or replies.
- A failure causes traffic on a link to flow in only one direction. This is called a unidirectional link.
One erroneous approach for decreasing the chances of a stuck-in-active route is to use multiple EIGRP autonomous systems to bound the query range. Many networks have been implemented using multiple EIGRP autonomous systems (to somewhat simulate OSPF areas), with mutual redistribution between the different autonomous systems. Although this approach changes how the network behaves, it does not always achieve the results intended. If a query reaches the edge of the autonomous system (where routes are redistributed into another autonomous system), the original query is answered. However, then the edge router initiates a new query in the other autonomous system. Therefore, the query process has not been stopped; the querying continues in the other autonomous system, where the route can potentially go in SIA.
Another misconception about autonomous system boundaries is that implementing multiple autonomous systems protects one autonomous system from route flaps in another autonomous system. If routes are redistributed between autonomous systems, route transitions from one autonomous system are detected in the other autonomous systems.
Preventing SIA Connections
SIA-Query and SIA-Reply are two new additions to the Type, Length, Value (TLV) triplets in the EIGRP packet header. These packets are generated automatically with no configuration required, from Cisco IOS Software Release 12.1(5) and later, with the Active Process Enhancement feature. This feature enables an EIGRP router to monitor the progression of the search for a successor route and ensure that the neighbor is still reachable. The result is improved network reliability by reducing the unintended termination of neighbor adjacency.
The diagram on the left in Figure 3-29 illustrates what would happen before this feature was introduced. Router A sends a query for network 10.1.1.0/24 to Router B. Router B has no entry for this network, so it queries Router C. If problems exist between Router B and C, the reply packet from Router C to Router B might be delayed or lost. Router A has no visibility of downstream progress and assumes that no response indicates problems with Router B. After Router A's 3-minute active timer expires, the neighbor relationship with Router B is reset, along with all known routes from Router B.
)
Figure 3-29 Cisco IOS Active Process Enhancement
In contrast, with the Active Process Enhancement feature, as illustrated in the diagram on the right in Figure 3-29, Router A queries downstream Router B (with an SIA-Query) at the midway point of the active timer (one and a half minutes by default) about the status of the route. Router B responds (with an SIA-Reply) that it is searching for a replacement route. Upon receiving this SIA-Reply response packet, Router A validates the status of Router B and does not terminate the neighbor relationship.
Meanwhile, Router B will send up to three SIA-Queries to Router C. If they go unanswered, Router B will terminate the neighbor relationship with Router C. Router B will then update Router A with an SIA-Reply indicating that the network 10.1.1.0/24 is unreachable. Routers A and B will remove the active route from their topology tables. The neighbor relationship between Routers A and B remains intact.
EIGRP Query Range
Limiting the scope of query propagation through the network (the query range), also known as query scoping, helps reduce incidences of SIA. Keeping the query packets close to the source reduces the chance that an isolated failure in another part of the network will restrict the convergence (query/reply) process. This section introduces an example that examines how to manage the query range.
Remote routers rarely need to know all the routes advertised in an entire network. Therefore, it is the network manager's responsibility to look at what information is necessary to properly route user traffic and to consider the use of a default route.
For example, in Figure 3-30, Router B notices the loss of network 10.1.8.0 and sends a query to Routers A, C, D, and E. In turn, these routers send queries to their neighbors, requesting an FS for 10.1.8.0. When the query process starts, each path receives duplicate queries because of the redundant topology. Therefore, not only are the remote routers required to respond to queries from the regional offices, but they also continue the search by reflecting the queries back toward the other regional office's router. This significantly complicates the convergence process on the network.
)
Figure 3-30 Effect of the EIGRP Update and Query Process
In this sample network with only two regional and three remote routers, the problem might not be very significant. In a network with hundreds of remote offices, the problem can be severe.
Examine the query process for the 10.1.8.0/24 subnet. Router B advertises 10.1.8.0/24 to all other routers. The best path for Router A to reach 10.1.8.0/24 is over the Ethernet link to Router B. The remote routers (C, D, and E) use the serial link to B as their preferred path to reach 10.1.8.0/24 but still learn about an alternative path through Router A. For this example, assume that the EIGRP metric for Ethernet is 1000 and the metric for a serial link is 100,000.
Table 3-5 shows the content of the IP EIGRP topology table on Routers C, D, and E for network 10.1.8.0/24. Table 3-6 shows the content of the IP EIGRP topology table on Router A for network 10.1.8.0/24.
Table 3-5. IP EIGRP Topology Table for 10.1.8.0/24 on Routers C, D, and E in Figure 3-30
|
Neighbor |
FD |
AD |
|
Router A |
102,000 |
2000 |
|
Router B |
101,000 |
1000 |
Table 3-6. IP EIGRP Topology Table for 10.1.8.0/24 on Router A in Figure 3-30
|
Neighbor |
FD |
AD |
|
Router B |
2000 |
1000 |
|
Router C |
201,000 |
101,000 |
|
Router D |
201,000 |
101,000 |
|
Router E |
201,000 |
101,000 |
Note that Routers C, D, and E determine that for network 10.1.8.0/24, Router B is the successor and Router A is an FS (because the AD is 2000 through Router A, which is less than the FD through Router B). Also, note that Router A does not have an FS, because all paths through the remote routers have an AD larger than the FD through Router B.
When Router B loses the path to network 10.1.8.0/24, it queries all four of its neighbors. When the remote sites receive this query, they automatically install the path through Router A in their routing tables and respond to Router B with their supposedly good path through Router A. They also remove the bad path through Router B from their topology tables.
Router B now has responses to three of its four queries, but it must wait until Router A responds as well.
When Router A receives the query from Router B for network 10.1.8.0/24, Router A creates a query and sends it to Routers C, D, and E, because Router A does not have an FS but knows that a path exists through each remote site to reach 10.1.8.0/24.
Routers C, D, and E receive the query from Router A; they now know that their path through Router A is not good, so they check their topology tables for alternative paths. However, none of these routers currently has another path, because Router B has just informed them that it does not have a path to this network. Because the remote routers do not have an answer to the query from Router A, Routers C, D, and E create a query and send it to all neighbors except the neighbor (interface) that these routers received the original query from. In this case, the remote routers send the query only to Router B.
Router B learns from these queries that none of the remote routers has a path to network 10.1.8.0/24, but it cannot respond that it does not know of a path, because Router B is waiting for Router A to reply to a query. Router A is waiting for either Router C, D, or E to reply to its query, and these remote sites are waiting for Router B to reply to their queries. Because Router B sent out the first query, its SIA timer expires first, and Router B reaches the SIA state for network 10.1.8.0/24 first (in 3 minutes by default). Router B resets its neighbor relationship with Router A. As soon as the neighbor relationship goes down, Router B can respond to Routers C, D, and E immediately, saying that Router B does not have a path to 10.1.8.0/24. Routers C, D, and E can then respond to Router A that they do not have a path.
After the EIGRP neighbor relationship between Routers A and B is reestablished (just after the adjacency is reset), Router B, which no longer has a path to 10.1.8.0/24, does not pass the 10.1.8.0/24 network to Router A. Router A learns that the remote sites do not have a path to 10.1.8.0/24, and the new relationship with Router B does not include a path to 10.1.8.0/24, so Router A removes the 10.1.8.0 network from its IP EIGRP topology table.
In Figure 3-30, the network architect provides redundancy with dual links from the regional offices to the remote sites. The architect does not intend for the traffic to go from a regional office to a remote office and back to a regional office, but unfortunately this is the situation. The design of the network shown in Figure 3-30 is sound, but because of EIGRP behavior, remote routers are involved in the convergence process.
If the remote sites are not acting as transit sites between the regional sites, the regional routers can be configured to announce only a default route to the remote routers, and the remote routers can be configured to announce only their directly connected stub network to the regional routers to reduce the complexity and the EIGRP topology table and routing table size.
The following section describes other solutions for limiting the EIGRP query range.
Limiting the EIGRP Query Range
The network manager must determine the information necessary to properly route user traffic to the appropriate destination. The amount of information needed by the remote routers to achieve the desired level of path selection must be balanced against the bandwidth used to propagate this information. To achieve maximum stability and scalability, the remote routers can use a default route to reach the core. If some specific networks need knowledge of more routes to ensure optimum path selection, a business decision is necessary to determine whether the benefits of propagating the additional routing information outweigh the additional bandwidth required to achieve this goal.
In a properly designed network, each remote site has redundant WAN links to separate distribution sites. If both distribution sites pass a default route to the remote sites, the remote sites load balance to all networks behind the distribution site routers. This maximizes bandwidth utilization and allows the remote router to use less CPU and memory, which means that a smaller and less expensive remote router can be used at that site.
If the remote site can see all routes, the router can select a path that is best to reach a given network. However, depending on the number of routes in the internetwork and the amount of bandwidth connecting the remote site to the distribution sites, this approach can mean that higher-bandwidth links or large routers are needed to handle the additional overhead.
After you determine the minimum routing requirements, you can make EIGRP more scalable. Two of the best options are the following:
- Configure route summarization using the ip summary-address eigrp command on the outbound interfaces of the appropriate routers.
- Configure the remote routers as stub EIGRP routers.
Other methods to limit query range include route filtering and interface packet filtering. For example, if specific EIGRP routing updates are filtered to a router and that router receives a query about those filtered (blocked) networks, the router indicates that the network is unreachable and does not extend the query any further.
Limiting Query Range with Summarization
One solution to limit the EIGRP query range is to use route summarization.
For example, in Figure 3-31, Router B sends a summary route of 172.30.0.0/16 to Router A. When network 172.30.1.0/24 goes down, Router A receives a query from Router B about that network. Because Router A has received only a summary route, that specific network is not in the routing table. Router A replies to the query with a "network 172.30.1.0/24 unreachable" message and does not extend the query any further.
)
Figure 3-31 EIGRP Summarization Can Limit Query Range
Summarization minimizes the size of the routing table, which means less CPU and memory usage to manage it and less bandwidth to transmit the information. Summarization reduces the chance of networks becoming SIA, because it reduces the number of routers that see each query, so the chance of a query encountering one of these issues is also reduced.
Figure 3-32 illustrates how route summarization can affect the network shown in Figure 3-30. The ip summary-address eigrp command is configured on the outbound interfaces of Routers A and B so that Routers A and B advertise the 10.0.0.0/8 summary route to the remote Routers C, D, and E.
)
Figure 3-32 Limiting Updates and Queries Using Summarization
The 10.1.8.0/24 network is not advertised to the remote routers. Therefore, the remote routers (C, D, and E) do not extend the queries about the 10.1.8.0/24 network back to the regional routers (A and B), reducing the convergence traffic (queries and replies) caused by the redundant topology. When Routers A and B send the query for 10.1.8.0/24 to Routers C, D, and E, these routers immediately reply to Routers A and B that the destination is unreachable. Queries for the lost 10.1.8.0/24 networks are not propagated beyond the remote sites, preventing Routers A and B from becoming SIA waiting for the query process to receive all the replies.
Limiting Query Range Using a Stub
Hub-and-spoke network topologies commonly use stub routing. In this topology, the remote router forwards all traffic that is not local to a hub router; the remote router does not need to retain a complete routing table. Generally, the hub router needs to send only a default route to the remote routers.
In a hub-and-spoke topology, having a full routing table on the remote routers serves no functional purpose, because the path to the corporate network and the Internet is always through the hub router. Additionally, having a full routing table at the spoke routers increases the amount of memory required. Route summarization and route filtering can also be used to conserve bandwidth and memory requirements on the spoke routers.
Traffic from a hub router should not use a remote router as a transit path. A typical connection from a hub router to a remote router has significantly less bandwidth than a connection at the network core; attempting to use the connection to a remote router as a transit path typically results in excessive congestion. The EIGRP stub routing feature can prevent this problem by restricting the remote router from advertising the hub router's routes back to other hub routers. For example, routes recognized by the remote router from hub Router A are not advertised to hub Router B. Because the remote router does not advertise the hub routes back to the hub routers, the hub routers do not use the remote routers as a transit path. Using the EIGRP stub routing feature improves network stability, reduces resource utilization, and simplifies stub router configuration.
The EIGRP stub feature was first introduced in Cisco IOS Release 12.0(7)T.
A stub router indicates in the hello packet to all neighboring routers its status as a stub router. Any neighbor that receives a packet informing it of the stub status does not query the stub router for any routes. Therefore, a router that has a stub peer does not query that peer.
The EIGRP stub routing feature also simplifies the configuration and maintenance of hub-and-spoke networks. When stub routing is enabled in dual-homed remote configurations, you do not have to configure filtering on remote routers to prevent them from appearing as transit paths to the hub routers.
To configure a router as an EIGRP stub, use the eigrp stub [receive-only | connected | static | summary] router configuration command. A router configured as a stub with this command shares information about connected and summary routes with all neighbor routers by default. Table 3-7 describes the four optional keywords that can be used with the eigrp stub command to modify this behavior.
Table 3-7. eigrp stub Command Parameters
|
Parameter |
Description |
|
receive-only |
The receive-only keyword restricts the router from sharing any of its routes with any other router within an EIGRP autonomous system. This keyword does not permit any other keyword to be specified, because it prevents any type of route from being sent. Use this option if there is a single interface on the router. |
|
connected |
The connected keyword permits the EIGRP stub routing feature to send connected routes. If a network command does not include the connected routes, it might be necessary to redistribute connected routes with the redistribute connected command under the EIGRP process. This option is enabled by default and is the most widely practical stub option. |
|
static |
The static keyword permits the EIGRP stub routing feature to send static routes. Redistributing static routes with the redistribute static command is still necessary. |
|
summary |
The summary keyword permits the EIGRP stub routing feature to send summary routes. You can create summary routes manually with the ip summary-address eigrp command or automatically at a major network border router with the auto-summary command enabled. This option is enabled by default. |
The optional parameters in this command can be used in any combination, with the exception of the receive-only keyword. If any of the keywords (except receive-only) is used individually, the connected and summary routes are not sent automatically.
In Example 3-21, the eigrp stub command is used to configure the router as a stub that advertises connected and summary routes.
Example 3-21. eigrp stub Command to Advertise Connected and Summary Routes
Router(config)#router eigrp 1 Router(config-router)#network 10.0.0.0 Router(config-router)#eigrp stub
In Example 3-22, the eigrp stub receive-only command is used to configure the router as a stub. Connected, summary, or static routes are not sent.
Example 3-22. eigrp stub Command to Receive Only Routes
Router(config)#router eigrp 1 Router(config-router)#network 10.0.0.0 eigrp Router(config-router)#eigrp stub receive-only
The EIGRP stub feature does not automatically enable route summarization on the hub router. The network administrator should configure route summarization on the hub routers if desired.
If a true stub network is required, the hub router can be configured to send a default route to the spoke routers. This approach is the most simple and conserves the most bandwidth and memory on the spoke routers.
Without the stub feature, EIGRP sends a query to the spoke routers if a route is lost somewhere in the network. If there is a communication problem over a WAN link between the hub router and a spoke router, an EIGRP SIA condition can occur and cause instability elsewhere in the network. The EIGRP stub routing feature allows a network administrator to prevent sending queries to the spoke router under any condition. Cisco highly recommends using both EIGRP route summarization and EIGRP stub features to provide the best scalability.
Figure 3-33 illustrates how using the EIGRP stub feature affects the network shown in Figure 3-30. Each of the remote routers is configured as a stub. Queries for network 10.1.8.0/24 are not sent to Routers C, D, or E, thus reducing the bandwidth used and the chance of the routes being stuck-in-active.
)
Figure 3-33 Limiting Updates and Queries Using the EIGRP Stub Feature
Using the EIGRP stub feature at the remote sites allows the hub (regional offices) sites to immediately answer queries without propagating the queries to the remote sites, saving CPU cycles and bandwidth, and lessening convergence time even when the remote sites are dual-homed to two or more hub sites.
Figure 3-34 illustrates another example network; Example 3-23 shows part of the configuration for Router B.
)
Figure 3-34 Network for eigrp stub Command Example
Example 3-23. Configuration for Router B in Figure 3-34
RouterB#show running-config <output omitted> ip route 10.1.4.0 255.255.255.0 10.1.3.10 ! interface ethernet 0 ip address 10.1.2.1 255.255.255.0 ! interface serial 0 ip address 10.2.2.3 255.255.255.254 ip summary-address eigrp 100 10.1.2.0 255.255.254.0 ! interface serial 1 ip address 10.1.3.1 255.255.255.0 ! router eigrp 100 redistribute static 1000 1 255 1 1500 network 10.2.2.2 0.0.0.1 network 10.1.2.0 0.0.0.255 <output omitted>
Using this example network and configuration, consider which networks will be advertised when the various options of the eigrp stub command are also configured on Router B:
- With the eigrp stub connected command, Router B will advertise only 10.1.2.0/24 to Router A. Notice that although 10.1.3.0/24 is also a connected network, it is not advertised to Router A because it is not advertised in a network command, and connected routes are not redistributed.
- With the eigrp stub summary command, Router B will advertise only 10.1.2.0/23, the summary route that is configured on the router, to Router A.
- With the eigrp stub static command, router B will advertise only 10.1.4.0/24, the static route that is configured on the router, to Router A.
- With the eigrp stub receive-only command, Router B will not advertise anything to Router A.
Graceful Shutdown
Graceful shutdown, implemented with the goodbye message feature, is designed to improve EIGRP network convergence.
In Figure 3-35, Router A is using Router B as the successor for a number of routes; Router C is the feasible successor for the same routes. Router B normally would not tell Router A if the EIGRP process on Router B was going down, for example, if Router B was being reconfigured. Router A would have to wait for its hold timer to expire before it would discover the change and react to it. Packets sent during this time would be lost.
)
Figure 3-35 Graceful Shutdown Causes Router to Say Goodbye
With graceful shutdown, a goodbye message is broadcast when an EIGRP routing process is shut down, to inform adjacent peers about the impending topology change. This feature allows supporting EIGRP peers to synchronize and recalculate neighbor relationships more efficiently than would occur if the peers discovered the topology change after the hold timer expired.
The goodbye message is supported in Cisco IOS Software Release 12.3(2), 12.3(3)B, and 12.3(2)T and later.
The following message is displayed by routers that support goodbye messages when one is received:
*Apr 26 13:48:42.523: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: Interface Goodbye received
A Cisco router that runs a software release that does not support the goodbye message will misinterpret the message as a K-value mismatch and therefore display the following message:
*Apr 26 13:48:41.811: %DUAL-5-NBRCHANGE: IP-EIGRP(0) 1: Neighbor 10.1.1.1 (Ethernet0/0) is down: K-value mismatch