interesting discussion.

a couple of thoughts of minor value.

1) one way to determine whether or not (E)IGRP is a distance vector or not
is to consider that (E)IGRP has a definite diameter limit that is
changeable. Several months ago there was a discussion on this board about
just that. If you have an (E)IGRP network with a diameter of, say, 25, and
you use the appropriate option to change the max distance to 23, some of
your routers and routes will disappear. Even though the routing table shows
(E)IGRP routes with some incomprehensible number in the metric column, the
fact is that the protocols are limited by hops

2) as an aside, I suppose it could be argued that all protocols are limited
by the IP TTL, but distance vector protocols all have built in limits to
their diameters. the link state protocols appear to have no such limits,
other than the structural one imposed by IP itself.

3) I think I am understanding that the "link" in link state refers to
something other than what I originally thought. Does "link" refer to the
neighbor state, the physical wire being up, both, neither?

once again, another great thread, clarifying a lot of things that I "already
knew"

Oh, one last thing - yes indeed, do not trust anything Cisco says on their
web site. The configuration information is fine. the theoretical stuff is
very often of questionable value. wish I could still find that link about
the reasons for the diameter limitation of EIGRP. It was hilarious.

Chuck




""Howard C. Berkowitz""  wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> At 4:47 AM -0400 5/14/02, Ouellette, Tim wrote:
> >Below is some information that i've pulled from Cisco.com
> >
> >Summary
> >Cisco Systems's EIGRP is one of the most feature-rich and robust routing
> >protocols to ever be developed. Its unique combination of features blends
> >the best attributes of distance vector protocols with the best attributes
of
> >link-state protocols. The result is a hybrid routing protocol that defies
> >easy categorization with conventional protocols.
> >
> >EIGRP is also remarkably easy to configure and use, as well as remarkably
> >efficient and secure in operation. It can be used in conjunction with
IPv4,
> >AppleTalk, and IPX. More importantly, its modular architecture will
readily
> >enable Cisco to add support for other routed protocols that may be
developed
> >in the future.
> >
> >Enhanced IGRP relies on four fundamental concepts: neighbor tables,
topology
> >tables, route states, and route tagging. Each of these is summarized in
the
> >discussions that follow.
> >
> >Other than the fact that cisco says EIGRP was developed from IGRP and
they
> >will redistribute between themselves automatically. I don't see the
> >similarity between them. I struggle to see how EIGRP is anything like a
> >distance-vector protocol.
> >
> >Tim
>
> In the most basic sense, routers operating in a distance vector
> algorithm exchange routes, cumulatively adding their own costs to a
> potential complete path to a destination.  Because the process is
> cumulative, it is more of a distributed processing model and thus
> potentially has less CPU demand.  Because it is cumulative, data may
> be old and inaccurate, which is where EIGRP and the DUAL algorithms
> have made advances to prevent.  Bellman-Ford and DUAL algorithms both
> are based on cumulative computation.
>
> Routers operating in a link state algorithm do not exchange routes,
> but send along information about specific "balls and string" --
> router nodes and the links directly connected to them.  A router
> receiving such information from a nonadjacent router doesn't do
> anything to it such as adding its own costs.  The router will simply
> pass it downstream to other routers, after applying sanity checks to
> see that it does not have more recent data.  When a link state router
> has complete data, it does an independent computation of best routes
> from its own data, using the Dijkstra algorithm and extensions. It
> does pass routes to the local router's routing table installation
> process and to processes with which it is redistributing, but it does
> NOT exchange routes with other routers in the same routing domain.
> Because the computation is of the entire topological data base, that
> computation tends to be more processor intensive, but also more
> accurate, than DV.  The computational intensity is the major reason
> that hierarchical structures are needed for LS protocols, because you
> need to limit the number of link states entering the computation.
> Typical OSPF intra-area computational load is proportional to the
> number of subnets times the logarithm of the number of routers.
>
> A major confusion that creeps into this comparison is that
> update-only mechanisms just happened to be introduced first WITH link
> state computation, but link state is in no way dependent on
> update-only mechanisms implemented with hello subprotocols.
>
> If you look at EIGRP's protocol exchanges, it exchanges routes, not
> link states, and it uses a hello protocol, which is independent of DV
> or LS status.




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=44229&t=43994
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]

Reply via email to