EIGRP Operation in an NBMA Environment and Large Networks

The Cisco EIGRP is a scalable option that provides support for point-to-point connections as well as NBMA point-to-point and multipoint links. This is another benefit of moving from IGRP to EIGRP and is a viable alternative to OSPF, depending on your environment.

As far as bandwidth is concerned , EIGRP looks at point-to-point Frame Relay interfaces just like any other serial interface and defaults to 1.544Mbps. Make sure that you configure your interfaces based on the Committed Information Rate (CIR) agreements with your vendor, corporate site, or area of your campus design.

Pure Multipoint Scenario

In a pure multipoint EIGRP WAN environment, one physical interface on the hub router is connected to two or more spoke routers that share identical CIRs for each circuit. In our first real-world scenario, we assume that you are setting the bandwidth for interface serial 1 on an EIGRP router configured in a pure multipoint frame relay topology. When configuring this environment, you must remember that the total bandwidth is shared equally among all the neighbors. For example, the hub router is connected to three remote sites and each is connected to the frame cloud by a 768Kbps CIR link ( fractional T1) that is supplied by your service provider. When configuring the bandwidth of interface serial 1 on the EIGRP hub router, you use the bandwidth 768 command divided by the number of frame relay virtual circuit neighbors. This configuration needs to be an accurate reflection of the percentages of actual available bandwidth on the cloud, as shown in Figure 7.4.

Figure 7.4. EIGRP in a pure multipoint frame relay environment.

Therefore, in this scenario, where three virtual circuits (VCs) have equal CIR values, you should issue the bandwidth 768 command to set the bandwidth for interface serial 1 on your hub router. This will provide enough bandwidth to support intervals of peak usage when all three sites are consuming their full allotment of bandwidth. The configuration for serial interface 1 would be as follows :

 RouterA(config-if)# interface serial 1 RouterA(config-if)# encap frame-relay RouterA(config-if)# bandwidth 768 

Hybrid Multipoint Scenarios

In our first hybrid multipoint scenario, an EIGRP hub router uses a single physical interface to connect three spoke routers that have unequal CIR values. In this case, you should multiply the number of VCs by the lowest CIR value when computing interface bandwidth to prevent the VCs with the smaller CIR value from being overloaded, as shown in Figure 7.5.

Figure 7.5. EIGRP hybrid multipoint with different CIR values.

In this situation, you want to multiply 56 (the lowest CIR value) by the number of virtual circuits (3) and configure the interface serial 1 with bandwidth 168 to prevent the slowest circuit from becoming saturated .

A better solution might be to configure your hybrid frame relay topology with a combination of multipoint and point-to-point operations. As shown in Figure 7.6, you can use subinterfaces on serial 1 to first configure the two higher CIR rates as a multipoint subinterface with a bandwidth equaling the total combined CIRs. Then you configure the single lower CIR (56Kbps) as a point-to-point interface with the bandwidth value being the total point-to-point circuit.

Figure 7.6. An EIGRP hybrid frame relay interface WAN configuration.

When determining a network type for a subinterface, only the multipoint and point-to-point keywords are valid. Listing 7.6 shows the configuration that you would perform on RouterA to accomplish this hybrid design.

Listing 7.6 A Sample Hybrid EIGRP Frame Relay Interface Configuration

 RouterA(config)# interface serial 0.1 multipoint RouterA(config-subif)# bandwidth 512 RouterA(config)# interface serial 0.2 point-to-point RouterA(config-subif)# bandwidth 56 

The EIGRP WAN configuration shown in Listing 7.6 and Figure 7.6 is an example of a hybrid multipoint topology. In situations in which different VCs have different CIRs, you can create subinterfaces on a single physical interface to provide the maximum possible bandwidth to each virtual circuit in the network. In this case, issuing the global configuration command shown in Listing 7.6 defines a multipoint serial interface that can be used to allocate bandwidth evenly between RouterB and RouterC. In a multipoint configuration, subinterface bandwidth is calculated by multiplying the number of VCs by the shared CIR value of both circuits. Because RouterB and RouterC are both connected to RouterA through a 256Kbps circuit, issuing the interface configuration command bandwidth 512 will provide sufficient bandwidth to both virtual circuits, even during times of peak usage when RouterB and RouterC are nearing their CIR bandwidth values. The slower circuit to RouterB is then placed on its own point-to-point subinterface as shown in Listing 7.6 above. You can then configure the subinterface bandwidth equal to the link's CIR by using the bandwidth 56 command in subinterface configuration mode.

You should compute the bandwidth value for each subinterface by specifying a percentage of the physical interface's total link capacity. For example, six point-to-point subinterfaces on a single 768Kbps frame relay serial connection would each be configured with 128Kbps of bandwidth so that you do not saturate any one interface.

As previously mentioned, if your Frame Relay cloud is oversubscribed, you can implement the ip bandwidth-percent commands on individual subinterfaces to properly allocate bandwidth. This takes a lot of preplanning and foresight to get it right the first time. That should be your priority when building a scalable EIGRP internetwork. The key factors to keep in mind throughout the process of configuring EIGRP operations in a scalable internetwork environment are the level of traffic flowing between neighbors, the rate of change to the topology, the number of routers, and the number of substitute paths in your EIGRP internetwork.

Stuck-in-Active (SIA)

Sometimes a router will fail to receive a reply to an unresolved query within a certain time interval (3 minutes for EIGRP). If this is the case, an EIGRP route will be considered in a state of stuck in active (SIA). If a successor route is unavailable and a router is unable to locate a feasible successor in the EIGRP topology table, the failed route enters the active state and begins querying neighbor routers for another path to the destination network. If another neighbor does have an alternate path , then an update packet is sent to the active router and the querying process ends. However, if the SIA router fails to receive a response to an outstanding query within the 3-minute time interval, the route is considered SIA. A router responds to an SIA route by immediately entering the active state for all routes learned through the failed neighbor. A router remains in an SIA state for a maximum of 3 minutes by default, after which the DUAL clears the adjacency with the neighbor that failed to reply to the query.

If a router running EIGRP drops a successor route and no feasible successor exists, the router goes into the active state for that particular route. A router that has gone active on a route sends query messages to all its neighbors (other than the unavailable neighbor) for an alternative route to the destination network. Because it could take more than 3 minutes for a query message to negotiate a large EIGRP internetwork, the timers active-time router configuration command can be used to set the time duration that a router running EIGRP will wait before declaring a route SIA. Here is the syntax for this command:

 RouterA(config-router)# timers active-time [  time-limit   disabled  ] 

The time-limit parameter is the threshold value (in minutes) that the querying router will remain in an active state before entering the SIA state. Some network engineers have attempted to lower the occurrence of SIA incidences by breaking an EIGRP AS into several autonomous systems to put boundaries on the query range. This does not necessarily solve the problem because the query can continue into the other AS where it can also go SIA.

The most effective approach for limiting the problem of SIA routes is to limit the range of EIGRP query propagation. Both route summarization and distribute lists can be implemented to place boundaries on the flood of query and update packets in an internetwork in which EIGRP is running. Distribute lists will be covered in detail in the chapters on BGP policy.