Scalable EIGRP Designs – Convergence Optimizations

This post covers in detail the characteristics of the EIGRP routing protocol such as convergence procedure, timer and query domain, and route selection.

Contents

• Topology
• EIGRP Convergence Process Overview
• Feasible Successors and Feasibility Condition
• Query Domain and Query Propagation
• Features to improve EIGRP Convergence Time
  • Feasible Successor
  • Loop Free Alternate Fast Reroute (LFA FRR)
  • Network Summarization
  • Route filtering
  • Stub Router
  • Different EIGRP AS numbers
• References

Topology

Figure 1

EIGRP Convergence Process Overview

EIGRP Queries are sent when a route goes down and no Feasible Successor routes exist. The router(s) that detects the loss declare the route as Active and sends Query messages to its neighbours, which forward the Query messages to its neighbours and so on, in order to find and alternative path. Convergence is a function of the Query Domain size.

 A router sends a Reply to a Query when:

• An exact match for a lost route is found: i.e. “I have an alternative path for the destination 10.20.30.0/24 and this is the metric”.
• There is a non-exact match for the lost route: i.e. “I don’t have an alternative path for the exact destination 10.20.30.0/24, I only have a summary (i.e. 10.20.0.0/16) or a default route (i.e. 0.0.0/0).” Automatically, a Reply with an infinite metric for 10.20.30.0/24 is sent.
• The router never knew about the route: i.e. “I do not have a route to 10.20.30/24 (%Prefix not found)”. A Reply with an infinite metric for 10.20.30.0/24 is sent.

For these three cases the router does not pass the Query message and the Query propagation stops.

This is only an overall view of the EIGRP Convergence process and in the following sections we are going to go deeper into some of the terms to understand better what has been described in the paragraphs above.

Successors and Feasibility Condition

Feasible Successors are EIGRP backup routes for a destination. In order to become a Feasible Successor the Feasibility Condition must be met:  “the reported distance of a route must be lower than the feasible distance (metric) of the current successor route. “

From R3’s point of view we are going to analyze the routing decision to go to R8’s loopback, 172.16.1.8/32. R3 has two possible paths, through R1 or through R2, and it is currently using R2 as next hop to the destination with a metric of 437760.

However, if we query the EIGRP database for the prefix 172.16.1.8/32 we can see that de second path through R1 is also available. Because the two paths have different metrics, R3 is not doing Equal Cost Multi Path (ECMP) routing. The metric through R2 is lower than the metric through R1 (437760<486400) so R2 is chosen as the Successor and it is preferred to reach the final destination.

Now the question is whether or not the path through R1 is a possible Feasible Successor to avoid the route to become Active if the path through R2 becomes unavailable to reach R8’s loopback. EIGRP desired behaviour is routes to be Passive (stable and converged) versus Active (actively looking for a path, not converged).

The key point to remember is if there are no Feasible Successors (backup routes), when a route becomes unreachable and goes into Active state a Query/Reply process is required and consequently the Convergence Time increases.

Feasibility Condition says:

R1’s reported distance < R3’s metric through R2 (Successor)

460800 < 437760

The condition is not met so the route becomes Active until the process of convergence is completed.

Query Domain and Query Propagation

Continuing with our example, R3 declares the route 172.16.1.8/32 (final destination) Active if, for example, R3’s connected link to R2 goes down. This is because the Feasibility Condition was not met.

Figure 2 shows this scenario where R3’s Fa1/0 goes down and the convergence process, Query/Reply packets, is triggered. Each router waits for Replies to its Queries before sending a Reply back to the upstream router who send the Query in the first place. Once the process is completed and an alternative path has been found the route becomes Passive.

Figure 2

The Convergence Time depends on the Query domain. The size of the Query domain represents all routers that receive a Query if a route is declared lost. If the number of routers in the Query domain is high, it directly implies higher Convergence Times. On the other hand, if we are able to reduce the Query domain size establishing network boundaries for Query messages that are capable to respond quickly to a Query with a Reply, the Convergence Times decrease. We will see in following sections some features to achieve this idea.

Then, we enable EIGRP debug on R3 to show the Query/Reply propagation process.

We simulate that R3’s Fa1/0 goes down shutting down the interface.

We can see Queries sent on Fa0/0 and Fa0/1 interfaces as well as the Replies coming from R1 and R5.

A capture done on R3’s Fa0/0 shows that R3 generates a Query message to 224.0.0.10 (EIGRP Multicast Address) to ask about an alternative path to the destination 172.16.1.8/32.

Figure 3

R1 sends a Reply to R3’s unicast address, 10.1.13.3, saying that there is an alternative path and including the new metric details. Now the final destination becomes Passive which is the desirable state.

Figure 4

The new route is installed on R3’s Routing Table.

Features to improve EIGRP Convergence Time

EIGRP Aggressive Timers (Fast Hellos) do not provide sub-second failure detection. Timers can be tuned to a minimum of 1 second however this is not recommended as it can be very CPU intensive and lead to spikes in processing/memory requirements. Bidirectional Forwarding Detection (BFD) is a preferred alternative in this case.

EIGRP Scalability features can be classified for:

• Paths with Feasible Successors: Convergence Time is in the milliseconds. The existence of Feasible Successors is dependent on the network design; consequently a good design is the key to fast convergence in an EIGRP network. Some features are:
  • Tune/engineer the network to make Feasible Successors available.
  • Loop Free Alternate Fast Reroute (LFA FRR).

• Paths without Feasible Successors, convergence time is dependent on the number of routers that have to handle and reply to the Query (Query domain). Some techniques make Queries be blocked one hop beyond:
  • Network Summarization.
  • Route Filtering.
  • Stub Router.
  • Different EIGRP AS numbers

Feasible Successor

Continuing with our example, as the network states right now, R3 sees two paths to R8’s loopback (172.16.1.8/32): through R1 and through R2. The path through R2 is chosen over R1’s path due to lower metric and R1 is not selected as a Feasible Successor because the Feasibility Condition is not met (460800 < 437760). Therefore, as we explained in previous sections, the route becomes Active and the Query Propagation mechanism is triggered.

The idea is to modify the EIGRP metric in order to comply with the Feasibility Condition and avoid going into Active state. We would have to increase the metric through R2 to get a higher value than the reported metric from R1 assuming we still want R2 to be the primary path.

R1’s reported distance < R3’s metric through R2 (Successor)

 460800 < R3’s metric through R2 (Successor)

In order to modify the EIGRP metric we are going to modify the delay as it is the preferred method of influencing path selection. Any change to the Bandwidth can have an impact on other Routing Protocol decisions or Quality of Service (QoS) preferences. The delay value chosen is arbitrary as long as the Feasibility Condition is met; I have chosen 110.

Now the Feasibility Condition is met:

R1’s reported distance < R3’s metric through R2 (Successor)

 460800 < 463360

If we repeat the same test that we did in the Query Domain and Query Propagation section and shut down R3’s link to R2 we can see the route to 172.16.1.8/32 does not become Active anymore (Queries are not sent).

The capture on R3’s Fa0/0 shows that the Query Packet does not include the prefix 172.16.1.8/32.

Figure 5

The capture on R3’s Fa0/1 shows that the Query Packet does not include the prefix 172.16.1.8/32.

Figure 6

R3 immediately starts using the Feasible Successor (R1) achieving sub-second convergence time.

The whole idea is to avoid the route to go Active and start the Convergence process (Queries/Replies). Being proactive we can have Feasible Successors already computed and ready to be used in case of a route loss.

Loop Free Alternate Fast Reroute (LFA FRR)

FRR is also a proactive mechanism that reduces traffic disruption to 10s of milliseconds in the event of link or node failure.  FRR uses existing Feasible Successors.

When a Successor fails, the Feasible Successor must be downloaded from the EIGRP topology table to the Routing Information Base (RIB) and from the RIB to the Forwarding Information Base (FIB). FRR pre-download Feasible Successors saving time in the Convergence process.

It is automatically enabled on all EIGRP interfaces covered by network statement although not all prefixes may have a Feasible Successor. Route-map is also available to enable FRR per prefix.

Up to this point, R3 already has a Feasible Successor through R1 for the specific route 172.16.1.8/32 and it is using R2 as primary path.

We now enable FRR on R3 for all routes. FRR is only available in EIGRP Named mode so first of all we run the command “eigrp upgrade-cli”  to automatically upgrade our configuration from EIGRP Classic to Named mode.

Once the conversion is done, we can finally enable FRR on R3.

R3’s routing information to 172.16.1.8/32 shows that the Repair Path (Feasible Successor) has been installed.

Network Summarization

EIGRP supports two types of summarization: auto-summarization and manual summarization. A big design advantage over Link State Protocols such as OSPF or IS-IS is that summarization can be enforce anywhere in the network.

Query propagation stops once the queried router cannot find the exact match for the requested subnet in its topology table but still has a route through a less specific match (for example a summary or a default route). According to this behaviour, summarization can help breaking the Query domain.

In the following example, R1 and R2 are configured to advertise the summary address 172.16.1.0/28 towards R3 and R4.

Figure 7

Although R1’s/R2’s routing table shows the more specific prefixes (172.16.1.7/32, 172.16.1.8/32) and the summary route (172.16.1.0/28), R3 only knows about the summary; the more specific prefixes are no longer advertised by R1 and R2.

In order to do our testing, we simulate that R7 looses reachibility to its loopback (Loopback7). Figure 8 illustrates the Convergence process. R7 sends a Query on its Fa0/0 and Fa0/1. R1 and R2 forward the Query to R3 and R4. R3 does not have a exact match for 172.16.1.7/32 instead it has a shorter match 172.16.1.0/28, the summary. Therefore, R3 answers with a Reply and breaks the Query domain not forwarding the Query to R5.

Figure 8

A capture done in the link between R7 and R1 shows the Query reaches R1’s Fa0/1.

Figure 9

The Query is passed to R3 from R1:

Figure 10

R3 sends a Reply back to R1 saying that 172.16.1.7/32 has an infinite metric (it is unreachable):

Figure 11

R3 does not forward the Query to R5. R3 becomes a boundary of the Query domain thanks to Summarization.

Figure 12

It is important to understand that a default route (0.0.0.0/0) would have had exactly the same result than using a summary route. The choice of using one option versus another really depends on the final network design.

The final goal is that having a less specific match for the prefix (172.16.1.0/28) versus having the exact match for the prefix (172.16.1.7/32)avoids passing forward the Query packet. We know there is no alternative path on the network but R7 to get to 172.16.1.7/32, the Convergence process is actually unnecessary in this scenario. However, this is how EIGRP behaves so we can always engineer the network with Summarization or Default Routes in order to improve the Convergence Time.

Route Filtering

As we mentioned at the beginning of this post, not having a route for a prefix makes the queried router to immediately respond to a Query with a Reply and stop the Query propagation. Therefore if 172.16.1.7/32 is filtered by R3, R5 will not be queried about this prefix because R3 (and R5 implicitly) never knew about it in the first place (the route is filtered).

Figure 13

We repeat the previous test: shutdown R7’s Loopback.

R3 receives the Query from R1 and R2 but it does not query R5 for 172.16.1.7/32.

Figure 14 shows a capture done in R3’s Fa0/0. We can verify that R3 receives the Query and sends a Reply back to R1 with an infinite metric ( delay: 4294967295) which means no route or route unreachable.

Figure 14

R5 never gets a Query about 172.16.1.7/32.

Figure 15

Again R3, using filtering in this case, becomes a boundary for the Query domain.

Stub Router

Stub routing is commonly used in a hub and spoke network topology. In a hub and spoke network a remote router (the spoke) is connected to one or more distribution routers (the hub). The remote router is adjacent only to one or more distribution routers. The only route for IP traffic to follow into the remote router is through a distribution router. In a hub and spoke topology, the remote router must forward all non-local traffic to a distribution router, so it becomes unnecessary for the remote router to hold a complete routing table. Generally, the distribution router need not send anything more than a default route to the remote router.

When using the EIGRP Stub Routing feature, you need to configure the distribution and remote routers to use EIGRP, and to configure only the remote router as a stub. A router that is configured as a stub will send a special peer information packet to all neighbouring routers to report its status as a stub router. Any neighbour that receives a packet informing it of the stub status will not query the stub router for any routes. The stub router will depend on the distribution router to send the proper updates to all peers.

Stub configuration reduces the Query domain, reduces load into the control plane and does not add time onto convergence.

In our scenario, we are going to configure R5 as EIGRP Stub. We simulate that R5 and R6 are part of a Remote Office connected to the Headquarters through R3. In reality, R5 uses R3 as the only possible path for any other non-local traffic so R5 becomes the exit point of the Remote Site’s network. Therefore, R5 does not need to know the routing details of the Headquarters’ network; it only needs to know that its default route is through R5. R5 becomes the perfect candidate for an EIGRP Stub.

Figure 16

R3 receives the stub flag from R5 and suppress the Queries. Note that by default a stub router only advertises CONNECTED and SUMMARY routes.

We repeat the test (shutdown R7’s Loopback) and we verify that R3 is not passing the Query to R5. However, R3 is still sending Queries on its Fa0/0 and Fa1/0 interfaces.

R5 is not receiving any Query from R3, however it is generating a Query towards R5 and R6 after receiving an Update from R3 saying that the route to 172.16.1.7/32 is lost. Remember that EIGRP Stub only prevents a Stub router from receiving Queries, Updates are forwarded.  Once R5 knows about the route loss, it triggers the Query process; a Stub router does not receive Queries from its neighbours but can originate Queries towards its non Stub neighbours.

R3 receives the Query from R5 asking for an alternative path to 172.16.1.7/32, because R3 does not have an entry for that route anymore immediately replies with a Reply packet and breaks the Query flooding.

Figure 17 shows the capture done on R5’s Fa0/1 towards R3.

Figure 17

If we check R3’s Routing Table we realized that the route to 172.16.1.6/32 (R6’s Loopback) is missed. The reason is that R5 only advertises Connected and Summary routes by default with the stub command. Therefore, we have to use a leak-map to also advertise 172.16.1.6/32 in addition to Connected and Summary routes to ensure full network reachibility.

It is also best practices to advertise a default route into the Remote Site in addition to EIGRP Stub feature. R6 does not have a full view of the network topology right now because R5 is doing filtering once it has been configured as Stub. Remember that R5 is only advertising Connected and Summary routes to its neighbours.

Figure 18

However, R6 is not receiving the default route from R5.

In order to ensure full network reachibility a static route has been configured on R6 for this specific scenario.

If we check the debug output and the captures we can see that in this case R3 does not even forward the Update about the loss of 172.16.1.7/32 to R5. R3 knows that is advertising a default route (0.0.0.0/0) and R5 does not need an Update about this specific prefix.

Capture between R1 and R3:

Figure 19

Capture between R3 and R5:

Figure 20

Different EIGRP AS Numbers

EIGRP processes run independently from each other, and Queries from one Autonomous System (AS) do not leak into another. However, if redistribution is configured between two processes a Query that results in not alternative path and the removal of the prefix from the Routing Table will originate a Query into the other AS. Therefore as per the regular query propagation rules, you may use prefix summarization when redistributing routes to limit the Query Domain.

References

https://www.cisco.com/c/dam/en/us/products/collateral/ios-nx-os-software/enhanced-interior-gateway-routing-protocol-eigrp/Advances_In_EIGRP.pdf

https://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/eigrpstb.html