| 0 comments ]

Designing Scalable EIGRP Designs

Add a note hereThis section focuses on designing advanced routing solutions using Enhanced Interior Gateway Routing Protocol. It describes how to scale EIGRP designs and how to use multiple EIGRP autonomous systems in a large network. Upon mastering this lesson, you will be able to describe and use various concepts to perform advanced routing design. This ability includes being able to meet these objectives:

  • Add a note hereDiscuss how to scale for EIGRP in a routing design

  • Add a note hereDiscuss design options with multiple autonomous systems


Scaling EIGRP Designs

Add a note here EIGRP is tolerant of arbitrary topologies for small and medium networks. This is both a strength and a weakness. It is useful to be able to deploy EIGRP without restructuring the network. As the scale of the network increases, however, the risk of instability or long convergence times becomes greater. For example, if a network has reached the point where it includes 500 routers, EIGRP may stop working well without a structured hierarchy. As the size of the network increases, more stringent design is needed for EIGRP to work well.


Note

Add a note hereThis mechanism contrasts with OSPF, where structured design is imposed at an early stage. The counterpart to using EIGRP with an arbitrary topology would be an OSPF design that puts everything into OSPF area 0. That also may work for small-to-medium networks, up to around 200 or 300 OSPF routers.

Add a note hereTo scale EIGRP, it is a good idea to use a structured hierarchical topology with route summarization.

Add a note hereOne of the biggest stability and convergence issues with EIGRP is the propagation of EIGRP queries. When EIGRP does not have a feasible successor, it sends queries to its neighbors. The query tells the neighbor “I do not have a route to this destination any more; do not route through me. Let me know if you hear of a viable alternative route.” The router has to wait for replies to all the queries it sends. Queries can flood through many routers in a portion of the network and increase convergence time. Summarization points and filtered routes limit EIGRP query propagation and minimize convergence time.

Add a note here EIGRP Fast Convergence

Add a note hereCustomers have been using EIGRP to achieve subsecond convergence for years. Lab testing by Cisco has shown that the key factor for EIGRP convergence is the presence or absence of a feasible successor. When there is no feasible successor, EIGRP uses queries to EIGRP peers and has to wait for responses. This slows convergence.

Add a note hereProper network design is required for EIGRP to achieve fast convergence. Summarization helps limit the scope of EIGRP queries, indirectly speeding convergence. Summarization also shrinks the number of entries in the routing table, which speeds up various CPU operations. The effect of CPU operation on convergence is much less significant than the presence or absence of a feasible successor. A recommended way to ensure that a feasible successor is present is to use equal-cost routing.

Add a note hereEIGRP metrics can be tuned using the delay parameter. However, adjusting the delay on links consistently and tuning variance are next to impossible to do well at any scale.

Add a note hereIn general, it is unwise to have a large number of EIGRP peers. Under worst-case conditions, router CPU or other limiting factors might delay routing protocol convergence. A somewhat conservative design is best to avoid nasty surprises.

Add a note here EIGRP Fast-Convergence Metrics

Add a note here This section discusses EIGRP fast-convergence metrics. Cisco tested convergence of various routing protocols in the lab (see Figure 3-7).

Click to collapse
Add a note hereFigure 3-7: EIGRP Fast Convergence

Add a note hereEIGRP convergence time increases as more routes need to be processed. However, there is a much bigger impact for networks without EIGRP feasible successors than for networks with no feasible successors.

Add a note hereWith a feasible successor present, EIGRP converges in times ranging from about 1/10 second for 1000 routes to about 1.2 seconds for 10,000 routes. Without the feasible successor, convergence times increased to ½ to 1 second for 1000 routes and to about 6 seconds for 10,000 routes.

Add a note hereSubsecond timers are not available for EIGRP. One reason is that the hello timer is not the most significant factor in EIGRP convergence time. Another is that experimentation suggests that setting the EIGRP timer below two seconds can lead to instability. The recommended EIGRP minimum timer settings are two seconds for hellos and six seconds for the dead timer. Subsecond settings are not an option.


Scaling EIGRP with Multiple Autonomous Systems

Add a note here Implementing multiple EIGRP autonomous systems is sometimes used as a scaling technique. The usual rationale is to reduce the volume of EIGRP queries by limiting them to one EIGRP autonomous system. However, there can be issues with multiple EIGRP autonomous systems (see Figure 3-8).

Image from book
Add a note hereFigure 3-8: Scaling EIGRP with Multiple Autonomous Systems

Add a note hereOne potential issue is with the external route redistribution. In the diagram, a route is redistributed from RIP into autonomous system 200. Router A redistributes it into autonomous system 100. Router B hears about the route prefix in advertisements from both autonomous system 200 and autonomous system 100. The AD is the same because the route is external to both autonomous systems.

Add a note hereThe route that is installed into the EIGRP topology database first gets placed into the routing table.

Add a note here Example: External Route Redistribution Issue

Add a note hereIf router B selects the route via autonomous system 100, it then routes to the RIP autonomous system indirectly, rather than directly via autonomous system 200, illustrated in Figure 3-9.

Image from book
Add a note hereFigure 3-9: Example: External Route Redistribution Issue

Add a note hereRouter B also advertises the route via autonomous system 100 back into autonomous system 200. Suppose B has a lower redistribution metric than router C does. If that is the case, A will prefer the route learned from B over the route learned from C. In this case, A will forward traffic for this route to B in autonomous system 200, and B will forward traffic back to A in autonomous system 100. This is a routing loop!

Add a note hereCisco addresses this slightly specialized situation through its bug fix CSCdm47037. Routing metrics are now also used as a tie-breaker in the situation. So, in the case where there are two routes with the same ADs, and the process type is the same, the metrics of the routes are compared, too.

Add a note here The same sort of behavior may be seen with redistribution between two routing protocols, especially for routes learned from the protocol with the lower AD.

Add a note here Filtering EIGRP Redistribution with Route Tags

Add a note hereOutbound route tags can be used to filter redistribution and support EIGRP scaling with multiple EIGRP autonomous systems (see Figure 3-10).

Click to collapse
Add a note hereFigure 3-10: Filtering EIGRP Redistribution with Route Tags

Add a note hereExternal routes can be configured to carry administrative tags. When the external route is redistributed into autonomous system 100 at router A or B, it can be tagged. This tag can then be used to filter the redistribution of the route back into autonomous system 200. This filtering blocks the formation of the loop, because router A will no longer receive the redistributed routes from router B through autonomous system 200.

Add a note hereIn the configuration snippets, when routers A and B redistribute autonomous system 200 routes into autonomous system 100, they tag the routes with tag 100. Any routes tagged with tag 100 can then be prevented from being redistributed back into autonomous system 200. This will successfully prevent a routing loop from forming.

Add a note here Filtering EIGRP Routing Updates with Inbound Route Tags

Add a note hereYou can filter EIGRP routing updates with inbound route tags to support scaling with multiple EIGRP autonomous systems (see Figure 3-11).

Click to collapse
Add a note hereFigure 3-11: Filtering EIGRP Routing Updates with Inbound Route Tags

Add a note here Filtering outbound tags in the previous example does not prevent router B from learning the routes from autonomous system 100. Router B could still perform suboptimal routing by accepting the redistributed route learned from autonomous system 100.

Add a note here The solution is to use inbound route tag filtering. This technique prevents routers from learning such routes, in which case they also will not be redistributed or advertised outbound. The Cisco bug fix CSCdt43016 provides support for incoming route filtering based on route maps. It allows for filtering routes based on any route map condition before acceptance into the local routing protocol database. This fix works for EIGRP and OSPF, starting with the Cisco IOS Software Releases 12.2T and 12.0S.

Add a note hereWhen routes are filtered to prevent router B from learning them, you prevent suboptimal routing by router B. The syntax shifts from using a route map with a redistribute command to using a route map with an inbound distribute-list command.


Note

Add a note hereThis example shows how filtering and administrative tags can help prevent routing loops with redistribution and suboptimal routing.

Add a note here Example: Queries with Multiple EIGRP Autonomous Systems

Add a note hereThis example looks at the query behavior with multiple EIGRP autonomous systems (see Figure 3-12).

Image from book
Add a note hereFigure 3-12: Example: Queries with Multiple EIGRP Autonomous Systems

Add a note hereIf router C sends an EIGRP query to router A, router A needs to query its neighbors. Router A sends a reply to router C, because it has no other neighbors in autonomous system 200. However, router A must also query all of its autonomous system 100 neighbors for the missing route. These routers may have to query their neighbors.

Add a note hereIn this example, the query from router C is answered promptly by router A, but router A still needs to wait for the response to its query. Having multiple autonomous systems does not stop queries; it just delays them on the way.


Note

Add a note here The conclusion of this example is that using multiple EIGRP autonomous systems as an EIGRP query-limiting technique does not work.

Add a note hereWhat really stops a query is general scaling methods using summarization, distribution lists, and stubs.

Reasons for Multiple EIGRP Autonomous Systems

Add a note hereThere could be several valid reasons for having multiple EIGRP autonomous systems, including these:

  • Add a note here Migration strategy after a merger or acquisition: Although this is not a permanent solution, multiple autonomous systems are appropriate for merging two networks over time.

  • Add a note here Different groups administer the different EIGRP autonomous systems: This scenario adds complexity to the network design, but might be used for different domains of trust or administrative control.

  • Add a note here Organizations with very large networks may use multiple EIGRP autonomous systems as a way to divide their networks: Generally, this type of design approach uses summary routes at autonomous system boundaries to contain summary address blocks of prefixes in very large networks and to address the EIGRP query propagation issue.

Add a note hereThese reasons for using multiple EIGRP autonomous systems can be appropriate, but careful attention must be paid to limiting queries.

0 comments

Post a Comment