Re: Fw: Is IGRP actually supported by other vendors? [7:43994]
Forgot to send this to list as well. - Original Message - From: Mike Mandulak To: Priscilla Oppenheimer Sent: Monday, May 13, 2002 4:13 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. He only gives a brief mention of EIGRP and says to refer to the CCNP study guide for more info. Lammle is quoting incorrect marketing information from Cisco. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44169t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Fw: Is IGRP actually supported by other vendors? [7:43994]
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 -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 3:53 AM To: [EMAIL PROTECTED] Subject: Re: Fw: Is IGRP actually supported by other vendors? [7:43994] Forgot to send this to list as well. - Original Message - From: Mike Mandulak To: Priscilla Oppenheimer Sent: Monday, May 13, 2002 4:13 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. He only gives a brief mention of EIGRP and says to refer to the CCNP study guide for more info. Lammle is quoting incorrect marketing information from Cisco. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44183t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Fw: Is IGRP actually supported by other vendors? [7:43994]
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=7i=44210t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Fw: Is IGRP actually supported by other vendors? [7:43994]
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
Re: Fw: Is IGRP actually supported by other vendors? [7:43994]
At 10:51 AM -0400 5/14/02, Chuck wrote: 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 That's not an essential part of DV, merely a practical sanity check. It is, of course, essential in RIP because RIP uses hop count as an interface cost in building its metric. 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? It's a somewhat unfortunate term, in that it doesn't precisely correspond to a concept in actual networking, but in graph theory. The Dijkstra algorithm builds a tree from an arbitrary root, and then grows links from there. In reality, router nodes generally form vertices and subnets form arcs, but that's not completely clear-cut, and it's just as easy, from a theoretical standpoint, to assume Dijkstra uses its own arbitrary vertices and treats all types of links as potential arcs (i.e., if they are on the best path). 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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44242t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Fw: Is IGRP actually supported by other vendors? [7:43994]
Forgot to send this to list as well. - Original Message - From: Mike Mandulak To: Priscilla Oppenheimer Sent: Monday, May 13, 2002 4:13 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. He only gives a brief mention of EIGRP and says to refer to the CCNP study guide for more info. - Original Message - From: Priscilla Oppenheimer To: Sent: Monday, May 13, 2002 3:19 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 02:44 PM 5/13/02, Mike Mandulak wrote: Lamme's CCNA study guide states that the courde and exam only covers distance-vector routing protocols (RIP and IGRP). If it only covers distance-vector, then it could cover EIGRP also. EIGRP is also distance-vector. I don't think the test does cover it, but it's not because the test only covers distance-vector. It's probably because of all the extra features in EIGRP, such as the diffusing update algorithm (DUAL), with the feasible successors and all that other BS. Come to think of it, maybe I'm glad I don't have to cover it! ;-) - Original Message - From: Priscilla Oppenheimer To: Sent: Monday, May 13, 2002 1:27 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Well, it occurs to me that IGRP would be easy to implement even without Cisco's permission. ;-) It's a simple protocol, for one thing. Also, the Rutgers paper that describes IGRP has been out for years. Cisco never objected to it. EIGRP would not be easy to implement without Cisco's blessings, developer support, licensed code, etc. We have probably all tried to figure out some detail of EIGRP or other and run into a brick wall. (For example, what does an router EIGRP really do with the MTU that is passed around in Updates? ;-) On a related tangent, will they remove IGRP from CCNA? I'm teaching a custom CCNA class next month, using my own materials. I find it annoying that I have to sort of downgrade my materials to teach IGRP theory and hands-on instead of the EIGRP I would prefer to teach and is already in my materials. But I think I'm right that CCNA expects IGRP and not EIGRP? Thx Priscilla At 04:02 AM 5/13/02, nrf wrote: In-line wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Nokia might support it, but I have been (fairly reliably) told that Cisco will *not* be supporting IGRP as of one of the newest IOS releases. I can't find the announcement on CCO (if there is one), so take with a grain of salt, but a Cisco instructor was quite adamant about this last week. That makes sense, considering it's literally been years since I've actually seen a bonafide production network running IGRP. So it makes sense that Cisco is finally ditching this dead wood. But I'm not asking this question because I'm champing at the bit to install a mixed Cisco/Nokia IGRP network. No, I'm asking because if it's true that Nokia really does support IGRP, then that begs the question - what other supposedly Cisco-proprietary technologies are like this too? I'm not talking about situations like what Howard stated where Cisco actually has an agreement to provide its technology to other vendors (somehow I doubt that Cisco and Nokia have such an agreement), but I'm talking about full-blown vendor compatibility between some other vendor and Cisco. For example, does anybody know of another vendor that supports, say, EIGRP? Or CDP? Now you might say that it would be impossible for another vendor to support these technologies, but, hey, Nokia apparently somehow managed to support IGRP, so why exactly couldn't somebody else support, say, EIGRP? JMcL - Forwarded by Jenny Mcleod/NSO/CSDA on 13/05/2002 04:44 pm - nrf Sent by: [EMAIL PROTECTED] 13/05/2002 01:42 pm Please respond to nrf To: [EMAIL PROTECTED] cc: Subject:Is IGRP actually supported by other vendors? [7:43994] Is this part of a business decision process?: Just found this while surfing around. As a network device, the Nokia IP330 supports a comprehensive suite of IP-routing functions and protocols, including RIPv1/RIPv2, IGRP, OSPF and BGP4 for unicast traffic... http://www.nokia.com/securitysolutions/platforms/330.html Every piece of literature I've ever read has stated without fail that IGRP is proprietary to Cisco. Yet here's Nokia brazenly claiming that they in fact support IGRP. What's up with that? Unfortunately I don't have an Ipso
Re: Fw: Is IGRP actually supported by other vendors? [7:43994]
At 04:20 PM 5/13/02, Mike Mandulak wrote: Forgot to send this to list as well. Please ignore my snooty comment about this in my message. ;-) I get irritated when people send messages directly to me. I thought you did it on purpose. Priscilla - Original Message - From: Mike Mandulak To: Priscilla Oppenheimer Sent: Monday, May 13, 2002 4:13 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. He only gives a brief mention of EIGRP and says to refer to the CCNP study guide for more info. - Original Message - From: Priscilla Oppenheimer To: Sent: Monday, May 13, 2002 3:19 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 02:44 PM 5/13/02, Mike Mandulak wrote: Lamme's CCNA study guide states that the courde and exam only covers distance-vector routing protocols (RIP and IGRP). If it only covers distance-vector, then it could cover EIGRP also. EIGRP is also distance-vector. I don't think the test does cover it, but it's not because the test only covers distance-vector. It's probably because of all the extra features in EIGRP, such as the diffusing update algorithm (DUAL), with the feasible successors and all that other BS. Come to think of it, maybe I'm glad I don't have to cover it! ;-) - Original Message - From: Priscilla Oppenheimer To: Sent: Monday, May 13, 2002 1:27 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Well, it occurs to me that IGRP would be easy to implement even without Cisco's permission. ;-) It's a simple protocol, for one thing. Also, the Rutgers paper that describes IGRP has been out for years. Cisco never objected to it. EIGRP would not be easy to implement without Cisco's blessings, developer support, licensed code, etc. We have probably all tried to figure out some detail of EIGRP or other and run into a brick wall. (For example, what does an router EIGRP really do with the MTU that is passed around in Updates? ;-) On a related tangent, will they remove IGRP from CCNA? I'm teaching a custom CCNA class next month, using my own materials. I find it annoying that I have to sort of downgrade my materials to teach IGRP theory and hands-on instead of the EIGRP I would prefer to teach and is already in my materials. But I think I'm right that CCNA expects IGRP and not EIGRP? Thx Priscilla At 04:02 AM 5/13/02, nrf wrote: In-line wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Nokia might support it, but I have been (fairly reliably) told that Cisco will *not* be supporting IGRP as of one of the newest IOS releases. I can't find the announcement on CCO (if there is one), so take with a grain of salt, but a Cisco instructor was quite adamant about this last week. That makes sense, considering it's literally been years since I've actually seen a bonafide production network running IGRP. So it makes sense that Cisco is finally ditching this dead wood. But I'm not asking this question because I'm champing at the bit to install a mixed Cisco/Nokia IGRP network. No, I'm asking because if it's true that Nokia really does support IGRP, then that begs the question - what other supposedly Cisco-proprietary technologies are like this too? I'm not talking about situations like what Howard stated where Cisco actually has an agreement to provide its technology to other vendors (somehow I doubt that Cisco and Nokia have such an agreement), but I'm talking about full-blown vendor compatibility between some other vendor and Cisco. For example, does anybody know of another vendor that supports, say, EIGRP? Or CDP? Now you might say that it would be impossible for another vendor to support these technologies, but, hey, Nokia apparently somehow managed to support IGRP, so why exactly couldn't somebody else support, say, EIGRP? JMcL - Forwarded by Jenny Mcleod/NSO/CSDA on 13/05/2002 04:44 pm - nrf Sent by: [EMAIL PROTECTED] 13/05/2002 01:42 pm Please respond to nrf To: [EMAIL PROTECTED] cc: Subject:Is IGRP actually supported by other vendors? [7:43994] Is this part of a business decision process?: Just found this while surfing around. As a network device, the Nokia IP330 supports a comprehensive suite of IP-routing functions and protocols, including RIPv1/RIPv2, IGRP, OSPF and BGP4 for unicast
