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.