This is the Introduction to Enhanced Interior Gateway Routing Protocol (EIGRP) most of this paragraph you will find here; moving swiftly along EIGRP is a Cisco Proprietary distance vector routing protocol that uses the same sophisticated metric that Interior Gateway Routing Protocol (IGRP) uses plus the Diffusing Update Algorithm (DUAL) convergences algorithm for loop-free routing. EIGRP is able to converge quickly and uses little bandwidth (like OSPF) because it separates keepalives, routing information and uses reliable updates. EIGRP is sometimes referred to as a hybrid routing protocol.
EIGRP was created (maybe read modified/updated) to solve scaling limitations that IGRP faced while still keeping the advantages of distance vector routing protocols (simplicity, economy of memory usage, and economy of processor resources). EIGRP is scalable in terms of hardware resources and network capacity. EIGRP is also very quick.
I use British English there will be a few small differences in spelling versus American English (the English Cisco Uses). Example: Neighbour vs Neighbor
Neighbourship and Reliable Incremental Updates
EIGRP supports several routed protocols independently (IP, IPX, Appletalk and IPv6) This means that each routed protocol has a best path that is not shared between other routed protocols.
EIGRP produces reliable (receiver ACKs the transmission was received and understood) updates by identifying its updates using IP protocol 88.
EIGRP uses five (5) types of packets to communicate:
- Hello - Identifies neighbours; Hellos sent via multicast periodically and ACK.
- Update – Advertises routes. Updates sent as multicast only when there is a change.
- ACK – ACK receipt of an update.
- Query – Used to ask about routes for which previous best path has been lost.
- If an update indicates that a path down, multicast queries used to ask other neighbours if they still have path.
- If querying router does not receive reply from each of its neighbours, it repeats query as a unicast to each unresponsive neighbour until it either gets a reply or gives up after sixteen (16) attempts.
- Reply – Used to answer query. Each neighbour responds to the query with a unicast reply indicating an alternative path or that it does not have a path.
Neighbour Discovery and Recovery
EIGRP uses a reliable update procedure; this creates two problems,
- The router needs to know how many other routers exist so that it knows how many ACK to expect.
- The router needs to know whether a missing advertisement should be interpreted as “no new information” or “neighbour disconnected”.
EIGRP uses neighbourship to address these problems (periodic hellos).
- The first hellos build a list of neighbours (Neighbour Table).
- following hellos indicate that the neighbours are still alive.
If hellos are missed (for the period of the hold time) then the neighbour is removed from the EIGRP table and routing reconverges.
The discovery process begins with multicast advertisements being sent out and individual routers replying with unicast ACK. The neighbour table tracks replies to make sure that each neighbour responds. If a neighbour does not respond with an ACK a follow-up unicast message is sent, after 16 times attempts the neighbour is removed from the neighbour table and EIGRP continues with its next task.
Sophisticated Metric
EIGRP uses a sophisticated metric that takes into account bandwidth, load, reliability, and delay. The metric equation is:
EIGRP selects paths based on the fastest path (lowest value). To do that it uses K-values (K1 to K5 in the equation). The K-values are constants(don’t change) that are used to adjust the relative contribution of the various parameters to the total metric. The EIGRP K variables are set as follows:
- Bandwidth – 107 kbps divided by the slowest link along the path. Because routing protocols select the lowest metric, inverting bandwidth makes faster paths have lower costs.
- Load and reliability – 8-bit calculated values based on the performance of the link. Both are multiplied by a zero K-value (neither used).
- Delay – a constant value on every interface type, and is stored in terms of microseconds (serial has a delay of 20,000 microseconds and Ethernet has a delay of 1000 microseconds). EIGRP uses a sum of all delays along the path, in microseconds.
By default:
- K1 = K3 = 1 and
- K2 = K4 = K5 = 0 (if you followed the maths if K5=0 then the metric equals 0).
Because the metric basically = 0 which will not be useful EIGRP ignores everything outside the parentheses.
Using the default K-values the equation then becomes:
Substituting the earlier description of variables, the equation becomes 10,000,000 divided by the chokepoint (worst/slowest link along the path) bandwidth plus the sum of delays:
Exercise to crystallize
This entire section is so that I understand how EIGRP selects the route using the below diagram (from Brent D, Stewarts CCNP book) lets plug in some values and see it work.
If we want to send traffic from Router A to Router D, which path would be used?
The top path ABCD has a chokepoint bandwidth of 768 Kbps and would go along 3 serial lines and look like this in the equation:
The bottom path AED has a chokepoint bandwidth of 512 Kbps and would go across 2 serial lines and look like this in the equation:
The result is that EIGRP chooses ABCD (top path) based on bandwidth.
Diffusing Update Algorithm (DUAL)
EIGRP uses the Diffusing update Algorithm (DUAL) which is a modification to the way distance-vector routing typically works. DUAL allows routers to identify loop-free failover paths. Using the same graphic as above lets do an exercise and figure out how DUAL works.
How DUAL works is that neighbouring routers advertise costs (using the below diagram. Lets say router A wants to send a packets to Router D). The two costs advertised by neighbours are as follows:
- To send a packet from A to D the Advertised Distance (AD) is either via BCD or ED and excludes the first hop.
- The other advertised metric is the Feasible Distance (FD) which is to send a packet the total distance ABCD or AED.
The idea that a path through a neighbour is loop free if the neighbour is closer is called the feasibility requirement and can be restated as “using a path where the neighbour’s advertised distance is less than our feasible distance will not result in a loop”.
The neighbour with the best path will be referred to as the successor. Neighbours that meet the feasibility requirements are called feasible successors. In emergencies, EIGRP knows that using feasible successors will not cause routing loops and instantly switches to the backup path.
Using the above diagram again I am going to be trying to reach Router D. What I did was plug in values using the same equation from the above exercise, just using each individual router (A, B, C, E) to get to D.
Queries
Having a Feasible Successor provides the best convergence. A feasible successor is a backup path and can be substituted should the active path go down at any point (without the need to change state and ask neighbours for a path). Should an active path go down and no Feasible Successor exist, a router will send out queries to remaining neighbours. If a neighbour does not know of a an alternative path, it will recursively ask neighbours.
Recursive queries can loop, forcing the router to time-out the query. This is known as stuck in active (SIA). EIGRP uses split horizon (a router should not advertise a network down a link from which it learned about the network – CCNA).
Queries will continue until an answer is found or until no one is left to query. When queries are produced the router changes to an Active State (actively querying for an alternative path) and sets a timer (3 minutes default). If the timer expires before an answer is returned the router is considered SIA. SIA typically occurs because queries are not properly limited to an area.
The primary way to limit how far queries travel (called query scoping) is to summarize (also allows quick convergence).
Incremental Updates
EIGRP periodically sends hellos to maintain neighbourship, but only sends updates when a change occurs. When a route is changed or withdrawn, an incremental update is sent including only those changes.
Multicast Addressing for Updates
EIGRP sends some packets using a reliable transport protocol (RTP). An example would be EIGRP sending a single multicast hello packet with an indicator that says it need not be ACK. Other types of packets like updates indicate that packet ACK is required.
EIGRP uses both multicast and unicast addressing.
Some packets are sent using Real-Time protocol (RTP), a Cisco Proprietary (?? Can’t find a source for this ??) protocol that oversees the communication of EIGRP packets. These packets are sent with sequence numbers to make the transmission of data reliable. Hellos and ACKs do not require acknowledgement.
Incremental Updates cannot be anticipated; update, query, and reply packets must be ACK by the receiving neighbour.
Updates are sent using reliable multicast (Reserved Class D address, 224.0.0.10). When a neighbour receives a multicast, it ACKs the receipt with an unreliable unicast.
Unequal-Cost load sharing
All IP routing protocols on Cisco routers support equal-cost load sharing. EIGRP is unique in its support for unequal-cost load sharing.
Unequal-cost load balancing takes the best FD and multiplies it by variance. Any other path with an FD less than this product (the product of multiplication read answer) is used for load sharing. EIGRP also does proportional unequal-cost load sharing.
EIGRP will pass a relative portion of the traffic to each interface (60/40) allowing links to a destination to be used to carry data without saturating the slower links or limiting the faster links.
Resources:
Stewart, Brent, D. 2008, CCNP BSCI Official Exam Certification Guide, 4th Ed. Indianapolis: Cisco Press.
Have a look at EIGRP Aragoen Celtdra notes on the same section of work
Internetworking Technology Handbook – EIGRP
Notes and Notices:
This is a part of my personal BSCI notes and research to assist myself in learning and understanding the concepts and theory for the BSCI exam. I learn by making notes reading and writing things down and wish to file them where I can’t lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BSCI Certification.
Open Shortest Path First – OSPF Fundamentals – Configuring Options On an Internal Router
To allow you to tune OSPF on an Internal Router you have the following options available at your disposal:
Defining the Router ID and Loopback interface
The Router ID (when thinking about OSPF Domains) is used to identify any given Router in the Link State Advertisements (LSAs) in an OSPF Database. A given Router on a network requires an ID (Router ID) to participate in an OSPF Domain. The Router ID can be assigned/set in one of two fashions:
In most configurations the Router ID is set by the administrator as this makes it easier to track events, internal documentation, and system-administration remotely or even on the router itself.
Setting the Router ID
The Router ID as discussed previously must be present for a Router to participate in an OSPF Domain. This Router ID can be set in one of two methods:
Setting the Router ID – Method One (Less Preferred)
The OSPF Router ID can be defined using the router-id (background link) command found in IOS.
Using the Router-ID command isn’t always the best idea when combining BGP and OSPF as both technologies employ the same method in electing a Router ID. So manually setting a Router ID (using the Router-id command) for OSPF could cause BGPs Router ID to differ from BGP which causes administration problems as well as could cause other problems at a later stage when combining the two technologies.
Should you still want to change the Router ID using this method anyway the command is:
Router(config)#router ospfRouter(config-if)#router-id ip-address
Dissecting the above when the Router ID has been chosen/assigned using the router-id command, the Router ID is kind of stable and may possibly change (barring a power cycle or a OSPF process reset). This is an important factor because changing the Router ID post (after) configuration could possibly break some OSPF configurations, such as virtual links (which as the name implies don’t exist, and could take some thinking to logically get working again).
Setting the Router ID – Method Two (Preferred)
Should the router-id command not be present/available on the router IOS you are using, and you want a more reliable method (sticky) that spans, the Router ID is automatically elected via:
I inherently look for the easier easier solution to a problem that will work long term, more work once off doesn’t matter (first off config) the solution must stick and continue working through power outages, reboots and the CEO trying his hand at “setting up” his own hardware, voice being a good example i.e. putting each end point into it’s own vlan thus ensuring QoS while the organization grows (there are limitations in the number of vlans, but I have yet to reach them).
Looking at the top the better method to control the Router ID (using automatic means) is through the use of the Loopback interface IP address. A loopback interface is a virtual interface (duh) that will always be active (cannot flap) and will be the first active interface (*shrug* logic dictates as it becomes the Router-ID, comments as I haven’t tested this out?).
The command to use a loopback is as follows (CCNA topic):
Router(config)#interface loopback inerface-numberRouter(config-if)#ip address ip-address subnet-mask
Consider assigning loopbacks a /32 mask 255.255.255.255 (1 end point) to minimize the ip space usage of the virtual interface(s) on the network (use it dont use it). I have come across some places that say that loopbacks wont work with the /32 mask (cant find source again), I will verify once I setup my kit again. In that case use the smallest (/31 or /30).
What I want to take away from this is should the Router ID be chosen/assigned using the loopback interface, the Router ID is stable and wont change. What’s important here is that a Loopback interfaces is NOT a physical interface thus cannot go up and down (flap) and therefore is not as unstable element in the network (i.e. loopback is stable) and thus is more desirable. Even in the event of a power cycle the loopback will once again be the Router ID.
Think about including the Loopback interface in the general network commands even if you aren’t configuring OSPF. This gives you an easy point to ping to should there be a need to troubleshoot (can I reach point A from point B) this should tell you alot about Layer 1 if the interface is un-shut and it has an ip-address.
Changing the COST
The COST metric on a Cisco is calculated as 100,000,000 bps divided by the bandwidth of the interface in bits per seconds. Sometimes when using a fast interface type (FE and GE) or when dealing with inter-vendor situations (Cisco / 3COM / HP) changing the default cost metric becomes a requirement (this is due to (1) faster link speeds not calculating correctly (2) or the metric equations being different between inter-vendor kit).
The command to change default cost:
Router(config-if)#ip ospf cost costThe cost variable is a 16-bit value (0 to 65,535). The lower values being the more preferred costs while higher being less preferred (shown below).
As you can see in the above table Fast Ethernet is the “drop off point” (where all things being 1) for the “fast” links (Fast Ethernet and Gigabit Ethernet both equal 1). In this case it would be better to manipulate the default cost so that the Gigabit Ethernet link is preferred over the Fast Ethernet Link. This would mean changing the cost per interface.
Another way to deal with high-bandwidth paths is to change the way a Cisco calculates cost (mess with the equation). We adjust the numerator in the automatic calculation (the Cisco automatic formula) to make some things happen in this case. To do this use the ospf auto-cost reference-bandwidth command on IOS, the default is 100 (Fast Ethernet) adjust it to 1000 (Gigabit Ethernet) and you will “fix” the equation.
Router(config-router)#ospf auto-cost reference-bandwidth reference bandwidthTwo very important NOTES (1) ospf auto-cost reference-bandwidth should be applied to all routers in an area if it is applied at all and the command (2) ip ospf cost overrides the calculated cost calculated by auto-cost reference-bandwidth
Determining the DR with the Priority Command
The hello field includes a priority field (if you can still remember) thus providing a mechanism by which designated router (DR) and backup designated Router (BDR) gets elected.
To be eligible for election, the priority must be a positive integer between 1 and 255 (if the priority is 0 (zero) the router cannot participate in the election process).
The highest priority wins (Cisco Router Default is 1) the election process.
Because the default is 1, to break all ties the Cisco Router ID is used as the deciding factor in the election process (ergo why hard coding the Router ID is a bad idea). The command to adjust priority (interface-by-interface mind you):
Router(config-if)#ip ospf priority numberNotes and Notices: This is a part of my personal BSCI notes and research to assist myself in learning and understanding the concepts and theory for the BSCI exam. I learn by making notes reading and writing things down and wish to file them where I cannot lose them. These notes are not to be seen, judged or mistaken for replacements to Cisco recognized and authorized training which I personally support and attend and suggest you undertake if you are going for the BSCI Certification.
If I added some value to your Cisco Experience with this post please add some value to my studies and leave a comment, question, suggestion, note of thanks or encouragement for me to hurry up and complete my certifications. My reasoning for wanting some interaction is that the last Recruiter said I need CCNP, Juniper and a Specialization track. The LOOOOONG Road to Cisco Indeed. Thanks Deon