Talk:Enhanced Interior Gateway Routing Protocol/Archive 1

The description of how this protocol actually works is woefully wrong, and seems to consist mostly of the Cisco marketing blather about how good it is. It is not in any way a link-state protocol, and does not have a complete topology map (even though the documentation speaks of "Topology Table" - which is basically just a copy of each neighbour's routing table). I did find one Cisco document that's reasonably technically accurate, and will reference it in the article. Are there actually any public-domain specifications of the protocol that we can reference? I found one thing that's pretty reasonable, will add that too. Noel (talk) 17:55, 15 Nov 2004 (UTC)

EIGRP is not a link-state protocol

I'm getting really tired of seeing the Cisco marketing balderdash about EIGRP being a "hybrid" of link-state routing and destination-vector routing spammed across Wikipedia, and even more tired of seeing repeatedly inserted after I keep removing it. I'm therefore going to spam this across every Talk: page where I see this claim, and a shorter note to the effect that EIGRP has no link-state stuff at all, in the articles.

Nothing could be further from the truth than the claim that EIGRP has any link-state aspects.

EIGRP is simply a multi-metric, event-driven, destination-vector routing protocol. Neither the "multi-metric" part nor the "event-driven" part has anything to do with link-state.

Link-state protocols have the following characteristics:

they distribute topology maps, not routing tables
nodes run a shortest-path algorithm such as Dijkstra over the map to produce the routing table

EIGRP does neither.

Clearly, one can design link-state protocols to be either event-driven, or not; all done to date (from the original "new" ARPANet routing algorithm) have been so, but that's purely a design decision. Event-driven or not-event-drive is a completely separate design axis.

Now stop adding this bogus nonsense! Noel (talk) 05:01, 24 Dec 2004 (UTC)

Formula problem

Following comment removed from text:

hm, is it

(K1*Bandwidth) + ((K2*Bandwidth)/(256-Load)) + ((K3*Delay) + (K5/(Reliability + K4)))

otherwise the below does not work:

Well, here's the exact formula from the source I used:

((K1*Bw) + (K2*Bw)/(256-Load) + (K3*Delay)*(K5/(Reliability + K4)))

Alas, their version is even more poorly paren'd than the one I gave! But you're right, it doesn't give the results they say it does. Looking at another Cisco document gives this equation:

Metric = [K1 * Bandwidth + (K2 * Bandwidth)/(256-load) + K3*Delay] * [K5/(reliability + K4)]

which looks equally problematoc. It goes on to say, however:

The default constant values are K1 = K3 = 1 and K2 = K4 = K5 = 0.

If K5 = 0, the [K5/(reliability + K4)] term is not used.

Mystery solved! Noel (talk) 19:50, 14 Dec 2004 (UTC)

I think the crucial line here "If K5 = 0, the [K5/(reliability + K4)] term is not used" is still missing from the entry's page. It should be added so that the formula in its present form make sense. User:Anon.

Claptrap

If Wikipedia has the intention of explaining things, this article absolutely misses that mark. I am not a computer professional and I understand little, if anything, of this article. Is it possible to write an article about EIGRP in English? Thuresson 05:22, 30 Mar 2005 (UTC)

What is it about this article that doesn't make sense? This question is open to anyone. Add examples of what you don't understand and someone may eventually rewrite that portion. I'm decently educated on how EIGRP works. I also teach to a certain degree and this article is geared more towards people who care how to calculate metrics than someone in passing who just wants to know what EIGRP is. User:Sean.nobles 00:40, 25 Sep 2005 (GMT)

I agree with Sean.nobles. And I have to disagree with Thuresson's complaint. Articles of a technical nature should not necessarily be watered down to make sense to every class of readers. The onus is to present as much of the most relevant information on the entry as possible. A non-technical reader who seems baffled by the internals of a routing protocol, might have their curiosity better satiated in the entry on Routers themselves. It doesn't make sense if I stumble on a technical article on the advantages of a quantum tunneling technique for photon pairing, that I complain of its inability to "explain" things - even though it could be very well written, but i wouldn't know it, since I know nothing of its context or discourse - and even call it "claptrap." Rather, I would just come to the conclusion that the article is more highly specialized than articles, say, on broader subject headings, like computer communication networks, or internetworking, or Routers, or photonics for that matter. Incidentally, I am a computer / IT professional, and I find this article very useful (especially as relates to the discussion on the metrics formula in this Discussion page - which clarifies the formula given on the main page I hope they update the main article with the extra info).User:Anon.

Does EIGRP handle IPv6 packet?

From reading Cisco documents between the lines, I get the perception that EIGRP will not be routing IPv6. I haven't read anthing that explicitly state so, but I wonder if there is anyone around here who might be better informed about Cisco's intention. i.e. Does none existance of EIGRP that can handle Ipv6 mean Cisco is finally throwing full support behind oSPF in future? Would such information be included in the article to make it more informative?

From Todd Lammle Sybex Cisco Author: EIGRP can run IPv6 but it runs as a separate protocol.

good place to start

The information presented gives the reader enough depth into EIGRP to get started. Router sims cisco publications, and good old hands on experience will fill in the rest of the blanks for practical usage.

From Todd Lammle, Sybex CCNA Author: The EIGRP protocol will run IPv6, but will run as a separate protocol. Please see my CCNA 6th edition for more information.

EIGRP 'Hybrid' Class

OK, This is from a CCNA textbook:

"Enhanced IGRP (EIGRP) is a classless, enhanced distance vector protocol that gives us a real edge over another Cisco proprietary protocol, Interior Gateway Routing Protocol (IGRP). That's basically why it's called Enhangced IGRP. Like IGRP, EIGRP uses the concept of an autonomous system to decribe the set of contiguous routers that run the same routing protocol and share routing information. But unlike IGRP, EIGRP includes the subnet mask in its route updates."

"EIGRP is sometimes referred to as a hybrid routing protocol because it has characteristics of both distance-vector and link-state protocols. For example EIGRP doesn't send link-state packets as OSPF does; instead, it sends traditional distance-vector traditional distrance-vector updates containing information about networks plus the cost of reaching them from the perspective of the advertising router. And EIGRP has link-state scharacteristics as well - it synchronizes routing tables between neighbors at startup, and then sends specific updates only when the topology changes occur."

(Source: Page 290 of CCNA Study Guide, Todd Lammle, ISBN 0-7821-4392-X)

So to say that EIGRP is a hybrid would be correct. If you have any doubts, complaints, whatnot, contact the author.

I disagree -- jerzy

This is a very week argument: quote from elementary CCNA (Cisco Certified Network Associate) study guide. I fully agree with noel's note in the beginning. Your quote: "And EIGRP has link-state scharacteristics as well - it synchronizes routing tables between neighbors at startup, and then sends specific updates only when the topology changes occur." The last part I would call asynchronous or event driven, nothing to do with maintaining full link-state topology table.

The point of the distance-vector routing algorithm is that router does not need to know full topology but only needs local knowledge of routing summary that it gets from its neighbors. Historically this was significant when routers memory and CPU was limited and savings, real or perceived where important. Dijksra's SPF calculations are CPU intensive and have been "stressful" for large networks for low end-routers that needed to do packet switching in CPU. The link-state vs. distance-vector wars are over, CPUs and memory plentiful but the misconceptions remain. Calling it a hybrid sounds like a compromise remaining from these wars. Chicken may look like a duck from distance but it will not fly or quack :-)