Enhanced Interior Gateway Routing Protocol (EIGRP).Stub Router functionality, which Cisco introduced in Cisco IOS® Software Release 12.0(7)T, provides network architects with greater flexibility for designing EIGRP networks by enabling improved control over traffic flows and limitations of query flooding.
Figure 1. Typical Hub and Spoke Network with Redundancy
This design is fairly typical for a large Enterprise environment. It features redundant hub routers with serial links (perhaps PPP or Frame Relay) to redundant routers located in a remote office. In some cases, for economic reasons, there may be a single router in the remote office, terminating the two serial connections, rather than the redundant configuration depicted in the illustration.
While such a level of redundancy is desirable, it also provides some interesting problems. If the backbone Ethernet link on Router A fails, then traffic to the remote site will begin to flow through Router B. If the network uses the Hot Standby Router Protocol (HSRP), this switchover can occur quickly. However, what if there was traffic passing from the 10.1.1.X subnet to the 10.1.2.X subnet? In this case, that traffic will have to pass through all four routers and traverse the remote office prior to being delivered to 10.1.2.X.
Suppose that the serial links in Figure 1 are very slow speed-perhaps 128 Kbps. In such a case, the slower speed links may not have sufficient bandwidth to support the traffic moving from 10.1.1.X to 10.1.2.X. An added consideration is that-as the backbone traffic attempts to traverse the low-speed links-it also consumes bandwidth resources that could be used by remote sites. Thus, both the central and remote sites experience degraded performance until the Ethernet link on Router A is repaired.
This design leads to a third issue: when an EIGRP route to a particular destination is lost, and no feasible successor route exists*, EIGRP will send a QUERY packet to each of its neighbors to discover if an alternate route exists. These neighbor routers, in turn, will replicate the QUERY to their neighbors until the QUERY reaches the very edges of the network.
Referring again to Figure 1, suppose that the Ethernet link to network 10.1.1.X is lost, and no feasible successor route exists. Router A will query routers B and C, who will query router D, and so forth. While this may not be a problem in the small network pictured here, let us further assume that this is a more typical Enterprise network, where the hub routers may be servicing 100 or more spoke routers at geographically diverse locations. The loss of a single link in this design can result in a flood of queries and query responses, severely impacting the scalability of the design.
SOLUTIONS
There are several solutions to some of the aforementioned problems:
• Add a redundant Ethernet link between routers A and B to contain the backbone traffic to the hub site
• Use some level of route summarization to limit the extents of the EIGRP QUERY mechanism.
• Configure a distribute-list to limit the networks advertised by the spoke routers.
However, the best solution is to provide a means within the context of the EIGRP protocol itself to control traffic flows and limit query depth. The EIGRP Stub Router functionality in Cisco IOS Software Release 12.0(7)T can achieve this solution.
In the EIGRP HELLO packet, which is used to establish adjacencies between EIGRP neighbors, a new Type-Length-Value (TLV) field has been added which allows a router to designate itself as a stub router. A stub router will only advertise the availability of a limited set of configured routes, rather than the entire routing table. The syntax for configuring an EIGRP stub router is:
• Static: router advertises any configured static routes
• Summary: router advertises any configured summarized routes
• Redistributed: router advertises any routes learned from another protocol, such as OSPF
The eigrp stub configuration need only be entered on the spoke routers. The hub routers determine that they are talking to a stub router by examining the TLV in the HELLO packet.
When a hub router determines that it is speaking to a stub router, the behavior also changes. A hub router will not send any QUERY packets to a stub router, because it knows that a stub router will only route packets for networks it has explicitly advertised. Thus, all QUERY packets to the stub routers on the network "spokes" are explicitly suppressed.
This new functionality neatly resolves the problems described in Section 2.0 of this document.
• Sub-optimal routing is eliminated because the stub spoke routers will only process traffic for which it has explicitly advertised availability
• Low-speed links are protected because high-bandwidth backbone traffic no longer traverses the spoke routers in the case of a backbone link failure
• Query storms are eliminated, which saves bandwidth and CPU and allows the network to converge more quickly.
DEPLOYMENT CONSIDERATIONS
• Once the stub router functionality is deployed on a spoke router, it will no longer accept or forward transit traffic for the backbone or for other spoke routers at different geographic locations. This behavior is generally desirable, because the link-speeds to the remote offices may not be appropriate to handle such traffic. However, some network administrators may believe that "some connectivity is better than none", and are willing to accept the degraded performance. In such cases, the EIGRP stub router functionality should not be configured.
• If using multi-access interfaces (e.g.: Frame Relay or ATM) and not using subinterfaces, then all remote spokes attached to that interface should be configured as EIGRP stub routers.
• To achieve the full benefit of the stub router functionality, the hub routers should also be upgraded to a version of code that supports it. Although the hub router should not be configured as a stub router, it needs the appropriate Cisco IOS Software release in order to understand the stub TLV and to suppress QUERY packets
• If an older version of code is deployed on the hub router, it will ignore the stub TLV and continue to send QUERY packets to the stub router. However, the stub router will immediately reply "inaccessible" to any QUERY packets, and will not continue to propagate them. Thus, the solution is backward-compatible and does not necessarily require an upgrade on the hub routers. However, Cisco recommends an upgrade, in order to realize the full benefits of the solution.
CONCLUSION
Network administrators who wish to provide greater EIGRP network stability, reduce resource utilization, and simplify configuration are advised to investigate the EIGRP stub router functionality. This new functionality resolves problems that have historically caused problems in designing efficient hub and spoke wide-area networks.
[an error occurred while processing this directive]
