EIGRP Stub Routing

 <  Free Open Study  >  

Technical Overview of EIGRP

EIGRP offers many advantages over other routing protocols, including the following:

  • Support for VLSM ” EIGRP is a classless routing protocol and carries the subnet mask of the route in its update.

  • Rapid convergence ” By using the concept of feasible successors, defined by DUAL, EIGRP is capable of preselecting the next best path to a destination. This allows for very fast convergence upon a link failure.

  • Low CPU utilization ” Under normal operation, only hellos and partial updates are sent across a link. Routing updates are not flooded and are processed only periodically.

  • Incremental updates ” EIGRP does not send a full routing update; it sends only information about the changed route.

  • Scalable ” Through the use of VLSM and a complex composite metric, EIGRP networks can be vast in size .

  • Easy configuration ” EIGRP supports hierarchical network design, but it does not require the strict configuration guidelines, such as the ones needed for OSPF.

  • Automatic route summarization ” EIGRP will perform automatic summarization on major bit boundaries.

  • MD5 route authentication ” As of Cisco IOS Software Release 11.3, EIGRP can be configured to perform MD5 password authentication on route updates.

Looking at this list, it becomes evident why EIGRP has become a popular routing protocol. It provides many of the enhancements of OSPF, without the strict configuration guidelines. It could be argued that EIGRP's weakest point is that it is a Cisco-proprietary protocol, but with the aid of redistribution, this point becomes moot.

EIGRP is a classless routing protocol. It directly interfaces to IP as protocol 88. EIGRP uses the multicast address of 224.0.0.10 for hellos and routing updates instead of an all- hosts broadcast like RIP uses. EIGRP also employs a system of hello and hold timers to maintain neighbors. Aside from the initial routing update, partial routing updates are sent only when network topology changes occur. The updates are also bounded, which means that updates are sent only to pertinent routers. Like IGRP, EIGRP uses a composite metric to calculate the best path to a destination. The sections that follow take a closer look at how EIGRP makes use of metrics, neighbors, reliable transport, and DUAL in its operation.

NOTE

Early releases of EIGRP had stability issues over low-speed serial links and problems maintaining many neighbors. Cisco significantly enhanced EIGRP with Cisco IOS Software Releases 10.3(11), 11.0(8), and 11.1(3) ” early releases of EIGRP are sometimes referred to as EIGRP version 1. Cisco currently ships routers with IOS 12.0 and above.


EIGRP Metrics

EIGRP uses metrics in the same way as IGRP. Each route in the route table has an associated metric. EIGRP uses a composite metric much like IGRP, except that it is modified by a multiplier of 256. Recall from Chapter 10, "Distance Vector Protocols: Interior Gateway Routing Protocol (EIGRP)," that bandwidth, delay, load, reliability, and MTU are the submetrics. Like IGRP, EIGRP chooses a route based primarily on bandwidth and delay, or the composite metric with the lowest numerical value. When EIGRP calculates this metric for a route, it calls it the feasible distance to the route. EIGRP calculates a feasible distance to all routes in the network. The following list is a detailed description of the five EIGRP submetrics:

  • Bandwidth ” Bandwidth is expressed in units of kilobits. It must be statically configured to accurately represent the interfaces that EIGRP is running on. For example, the default bandwidth of a 56-kbps interface and a T1 interface is 1544 kbps. To accurately adjust the bandwidth, use the bandwidth kbps interface subcommand. Table 11-1 highlights some common bandwidth values.

  • Delay ” Delay is expressed in microseconds. It, too, must be statically configured to accurately represent the interface that EIGRP is running on. The delay on an interface can be adjusted with the delay time_in_microseconds interface subcommand. Common delay values are represented in Table 11-1.

  • Reliability ” Reliability is a dynamic number in the range of 1 to 255, where 255 is a 100 percent reliable link and 1 is an unreliable link.

  • Load ” Load is the number in the range of 1 to 255 that shows the output load of an interface. This value is dynamic and can be viewed using the show interfaces command. A value of 1 indicates a minimally loaded link, whereas 255 indicates a 100 percent loaded link.

  • MTU ” The maximum transmission unit (MTU) is the recorded smallest MTU value in the path, usually 1500.

NOTE

Whenever you are influencing routing decisions in IGRP or EIGRP, use the metric of delay over bandwidth. Changing bandwidth can affect other routing protocols, such as OSPF. Changing delay affects only IGRP and EIGRP.


Table 11-1 highlights the common metrics used.

Table 11-1. Common IGRP and EIGRP Metrics
Medium Bandwidth Delay
100-Mbps ATM 100,000 kbps 100 microseconds
Gigabit Ethernet 100,000 kbps 100 microseconds
Fast Ethernet 100,000 kbps 100 microseconds
FDDI 100,000 kbps 100 microseconds
HSSI 45,045 kbps 20,000 microseconds
16-Mbps Token Ring 16,000 kbps 630 microseconds
10-Mbps Ethernet 10,000 kbps 1000 microseconds
T1 1544 kbps 20,000 microseconds
DS-0 64 kbps 20,000 microseconds
56-kbps media 56 kbps 20,000 microseconds

EIGRP uses a composite metric (CM) that is derived from the five submetrics. When EIGRP computes the composite metric, it uses a formula that involves five constants or "k" values. The constant values have default value such as the following:

graphics/11equ01.gif


By setting k2, k4, and k5 to 0, it essentially nullifies the submetrics of load, reliability, and MTU. This is precisely why you should first use delay and then bandwidth when trying to influence which routes EIGRP prefers. The formula EIGRP uses to calculate the composite metric is as follows :

graphics/11equ02.gif


where the following is true:

graphics/11equ03.gif


With the k values set at the default value you have

graphics/11equ04.gif


NOTE

The router calculation of the composite metric will always differ slightly from the result when it is performed by longhand. This is because of the way the router handles floating-point mathematics; there will be slight rounding discrepancies.


Using the default values of constants, k1 = k3 = 1 and k2 = k4 = k5 =0, the formula quickly breaks down to this:

graphics/11equ05.gif


Substituting the constants, you have the following:

graphics/11equ06.gif


NOTE

For reference, the metric is computed the same way for IGRP, except the result of bandwidth and delay is not multiplied by 256, and the DELAY sum variable is divided by 10.

graphics/11equ02.gif


where the following is true:

graphics/11equ12.gif


With k values set at the default value, you have:

graphics/11equ13.gif



To demonstrate composite metric calculation, refer to Figure 11-1. In this example, EIGRP calculates a composite metric on the alpha router to 172.16.1.0/24, which resides on the charlie router.

Figure 11-1. EIGRP Routing Updates

graphics/11fig01.gif

Assuming that the bandwidth statements been set by an astute engineer, the lowest bandwidth on the path between alpha and charlie routers would be 56. Therefore, you have

graphics/11equ07.gif


The delay is the summation of the delays on the outbound interfaces only. The summation ends with the delay on the interface in which the final subnet resides. From alpha to bravo, the delay is 20000; from bravo to charlie, it is 1000; this includes the final interface on charlie, which has a delay of 1000. Therefore, you have

graphics/11equ08.gif


The composite metric now yields the following:

graphics/11equ09.gif


The submetrics and the composite metric can be confirmed by performing the show ip route 172.16.1.0 command on the alpha router, as in Example 11-1. Remember, because of rounding errors, the metric does not match exactly.

Example 11-1 show ip route Command Output Highlighting the EIGRP Metrics
 alpha#  show ip route 172.16.1.0  Routing entry for 172.16.1.0/24  Known via "eigrp 65001", distance 90, metric 46277376, type internal  Redistributing via eigrp 65001   Last update from 172.16.3.1 on Serial7, 00:50:53 ago   Routing Descriptor Blocks:   * 172.16.3.1, from 172.16.3.1, 00:50:53 ago, via Serial7       Route metric is 46277376, traffic share count is 1       Total delay is 22000 microseconds, minimum bandwidth is 56 Kbit       Reliability 255/255, minimum MTU 1500 bytes       Loading 1/255, Hops 2 alpha# 

When using metrics to influence routing decisions, use the delay xx interface command. Be sure to include a delay at each side of the interface if you want symmetrical routing ”that is, packets will take the same route back to the source. By default, EIGRP will perform equal-cost load balancing over routes. For example, if you perform a show ip route command and see two routes to a destination reported , EIGRP will load-balance over those routes.

To demonstrate the use of the delay metric, we have added another Ethernet segment between the bravo and charlie routers and a loopback interface, 172.16.128.1/24, on the charlie router, as illustrated in Figure 11-2.

Figure 11-2. EIGRP Load Sharing

graphics/11fig02.gif

If you perform a show ip route command on the bravo router, as shown in Example 11-2, you see two routes to the 172.16.128.0/24 network. The show ip eigrp topology command also lists the routes and the composite metric to them.

Example 11-2 Two Routes Reported to 172.16.128.0/24
 bravo#  show ip route  Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP        D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area        N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2        E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP        i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, * - candidate default        U - per-user static route, o - ODR Gateway of last resort is not set      172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks D       172.16.128.0/24 [90/409600] via 172.16.2.1, 00:23:50, Ethernet4                         [90/409600] via 172.16.16.1, 00:23:50, Ethernet5 C       172.16.16.0/24 is directly connected, Ethernet5 C       172.16.2.0/24 is directly connected, Ethernet4 C       172.16.3.0/30 is directly connected, Serial1 bravo# 

If you want EIGRP to prefer one path to the other, add the delay command on each side of the interface. It is important to note that changing the delay of a link will affect only the routing protocol, not the actual throughput of the link.

Continuing with the example, set the delay of the link so that the primary link to 172.16.128.0 will be through 172.16.16.1. This can be accomplished by adding a delay of 1000 to the e4 interface of the bravo router and under the e0/1 interface of the charlie router. Example 11-3 demonstrates the configuration of delay on the bravo router.

Example 11-3 Addition of the delay Command
 bravo#  conf t  Enter configuration commands, one per line.  End with CNTL/Z. bravo(config)#  int e4  bravo(config-if)#  delay 1000  bravo(config-if)#  ^Z  

Example 11-4 shows the route table of the bravo router after the delay was added to the bravo and charlie routers.

Example 11-4 One Route to the 172.16.128.0/24 Route
 bravo#  show ip route  172.16.0.0/16 is variably subnetted, 4 subnets, 2 masks D       172.16.128.0/24 [90/409600] via 172.16.16.1, 00:00:11, Ethernet5 C       172.16.16.0/24 is directly connected, Ethernet5 C       172.16.2.0/24 is directly connected, Ethernet4 C       172.16.3.0/30 is directly connected, Serial1 bravo# 

Keep in mind that although the second route is removed from the routing table, EIGRP still knows of the route and will keep it as a feasible successor.

The k values also can be manipulated to influence routing decisions. This can be accomplished with the metric weights tos k1 k2 k3 k4 k5 command. Manipulating these values directly impacts how EIGRP derives the composite metric for all routes. Change the metric weights only when working with Cisco to solve specific problems.

EIGRP Neighbors

EIGRP does not periodically advertise it routes. Because of this, it needs some way to locate and then exchange routing information with adjacent devices. EIGRP accomplishes this through the use of neighbors. When EIGRP initializes, it sends out a multicast hello on address 224.0.0.10, on broadcast media. On NBMA media, X.25, Frame Relay, and ATM, the hellos are unicast every 60 seconds. EIGRP continues to send out hellos every few seconds, based on the media type. Specifically, EIGRP sends hellos every 5 seconds on the following interfaces:

  • LAN broadcast media, such as Ethernet, Token Ring, and FDDI

  • High-speed serial link greater than T1 speeds, such as Frame Relay HSSI links

  • Point-to-point serial links, such as PPP or HDLC

  • ATM and Frame Relay point-to-point subinterfaces

EIGRP sends hellos every 60 seconds on the following interfaces:

  • Low-speed serial links less than T1 speeds, including Frame Relay and multipoint X.25

  • ATM and Frame Relay multipoint interfaces, and ATM SVCs

  • ISDN BRIs

Routers that reside on the same network receive the multicast hello and respond to form what is called an adjacency . Figure 11-3 and the list that follows describe the initial router exchange when forming an adjacency:

Figure 11-3. EIGRP Neighbor Establishment

graphics/11fig03.gif

  1. Hellos are sent out each interface participating in EIGRP, except interfaces quieted by the passive interfaces. All EIGRP hellos and routing updates use the multicast address of 224.0.0.10.

  2. Routers on the same IP subnet receive the multicast and respond with a full routing update. This is accomplished by setting the INITialization bit in the EIGRP header; the updates include all networks that EIGRP is aware of and the metric for those routes, except for those suppressed by split horizon. This update packet establishes a neighbor relationship (adjacency). The hello packet also includes a hold timer, which tells the router how long it should wait before receiving a hello and declaring the route unreachable and reporting it to the DUAL process. The hold timer is set to three times the value assigned for the hello timer. This usually is 15 or 180 seconds, depending on the media.

  3. The bravo router responds to the initialization packet by sending a hello with the ACK bit set. EIGRP sets the ACK bit to acknowledge all messages that it receives that have data. This is one way that EIGRP has reliable transports (discussed further in upcoming sections).

  4. The bravo router now inserts the new update into its route table. Because it has a new update, it sends an update to all its neighbors.

  5. The neighbors that received the update from the bravo message respond with an acknowledgment packet.

  6. The router holds the adjacency by the continuous exchange of hellos. If a hello is not received by the time the hold timer expires , the router marks the route as unreachable.

When the router forms an adjacency, it treats this as a virtual link to transport routing information.

The router begins to form a neighbor table with the following information:

  • The IP address of the router that it received the hello from

  • The hold timer

  • The SRTT or round-trip time

  • The uptime of the neighbor

The status of neighbors can be displayed with the show ip eigrp neighbors command, as in Example 11-5. The uptime of the neighbor should be for as long as the adjacency has been established.

Example 11-5 show ip eigrp neighbors Command Output on the bravo Router
 bravo#  show ip eigrp neighbors  IP-EIGRP neighbors for process 65001 H   Address                 Interface   Hold Uptime   SRTT   RTO  Q  Seq                                         (sec)         (ms)       Cnt Num 1   172.16.2.1              Et4           12 01:10:36    8   200  0  29 2   172.16.16.1             Et5           13 02:14:15    3   200  0  28 0   172.16.3.2              Se1           11 07:07:44   23  2604  0  23 bravo# 

Stable EIGRP neighbors are the single most important element in any EIGRP network. Without stable neighbors, an EIGRP network will have difficulty operating properly. Checking the status of EIGRP neighbors should be the first step in verifying the operational status of any EIGRP network.

EIGRP Reliable Transport Protocol (RTP)

RTP ensures that EIGRP packets are received, delivered, ordered, and acknowledged . To guarantee delivery, EIGRP employs the use of a Cisco proprietary reliable multicast message. When each neighbor receives a reliable multicast packet, it is required to respond with a unicast acknowledgment. Updates also have sequence numbers ; this is how the router ensures that updates are in the proper order. To facilitate RTP and the other functions of EIGRP, Cisco uses four primary types of packets, even though there are actually five. As previously mentioned, all EIGRP packets directly interface with the IP layer as protocol 88, and the multicast updates use the IP address of 224.0.0.10. The five packet types are as follows:

  • Hello ” Used to discover and maintain neighbors. This packet type uses unreliable delivery.

  • Acknowledgments (ACKs) ” Used to acknowledge updates. They are essentially hellos with no data in them. ACKs also use unreliable delivery.

  • Updates ” Contain routing information. Updates can be either unicast or multicast, depending on how they are generated. Updates use reliable delivery.

  • Queries ” Used by the DUAL process to find feasible successor for routes. The query can be unicast or multicast. Queries always use reliable delivery.

  • Replies ” Used by the DUAL process to aid in finding feasible successor for routes. Replies are always unicast and use reliable delivery.

NOTE

Some documentation refers to queries and replies as the four and fifth types of packets. The actual fifth type of packet is a request. The request never was implemented in EIGRP and was intended for route servers. IPX SAPs also use another Opcode in the EIGRP header, making them another packet type.


Diffusing Update Algorithm

The DUAL algorithm is the " brains " of EIGRP, responsible for tracking all routes by all neighbors and ensuring a loop-free topology. It is based on an algorithm first developed by E.W. Dijkstra and C.S. Scholten, and later enhanced by J.J. Garcia-Luna-Aceves.

With the help of DUAL, EIGRP and the processes previously covered, EIGRP keeps the following tables:

  • Neighbor table ” EIGRP tracks every formed adjacency in the neighbor table. A neighbor will be held until an ACK is not received after 16 unicast retransmissions to that neighbor. At this time, the neighbor is dropped. Neighbors can be displayed with the show ip eigrp neighbors command.

  • Topology table ” All learned routes reported by neighbors are kept in the topology table. The topology table also tracks the metrics and feasible distances associated with those routes. The topology table can be displayed with the show ip eigrp topology as_number command.

  • Route table/forwarding table ” Only the routes with the lowest composite metric are entered into the final route or forwarding table. This is the route that the router will forward to.

The process that DUAL uses to perform a loop-free topology is a detailed process. EIGRP has what is called a feasible successor and a successor to every route in its route table. The successor is the primary path for the route, or the path that the router will forward packets to. The feasible successor becomes the next-hop address only if the primary route to the destination becomes unreachable. The feasible successor is always downstream and, thereby, must have a distance or feasible distance that is less than that of the current preferred route. This prevents routing loops because the downstream router must always have a feasible cost lower than that of the current cost of the route to be considered as a feasible successor.

The DUAL process is in control of determining feasible distances, feasible successors, and the successor of the routes in the EIGRP topology table. By having a backup path already defined in the topology table, the router can quickly converge to the new path in case the primary path fails.

Protocol-Dependent Modules

EIGRP is one of the few routing protocols that can work with multiple routed protocols. Cisco implements what it calls protocol-dependent modules in the code that handle protocol-specific tasks . For example, IPX EIGRP needs to send and receive SAP updates. IP and IPX form neighbors using different message formats.

EIGRP operates the same way for all routed protocols ”that is, it uses DUAL to find the shortest path to forward data toward. Another task of protocol-dependent modules is to pass data into the DUAL process so that a proper topology table, and eventually a route table, can be formed.

Like IGRP, EIGRP deploys the concepts of split horizon and poison reverse to prevent routing loops.

 <  Free Open Study  >  


CCIE Practical Studies, Volume I
CCIE Practical Studies, Volume I
ISBN: 1587200023
EAN: 2147483647
Year: 2001
Pages: 283
Authors: Karl Solie

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net