Re: Is IGRP actually supported by other vendors? [7:43994]
Couple thoughts here Rick. First off, always consider that there may be (and usually are) flaws in secondary source material and thus don't believe everything you read.Beyond that, I have a couple questions related to the matter. Primarily, what exactly is a hybrid routing protocol? Hybrid is a pretty ambiguous term if you ask me. Additionally, what elements of link state routing are evident in the EIGRP implementation? Simply because a protocol happens to build adjacencies via hello packets does not categorize it as a link state protocol. I'd fully concur with Priscilla's description of the details and Howard B also has written similar on this topic in his Scalable Link State Routing series on www.certificationzone.com. At 06:42 PM 5/13/2002 -0400, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts he network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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 cl
Re: Is IGRP actually supported by other vendors? [7:43994]
Sorry if this turns up twice - seems to be a problem with the groupstudy mail server? Rick, Since you seem so certain, in what way is EIGRP a link-state protocol? What link-state attributes does it have? I haven't read all of the article at the link you've given, but I note that in the intro what it actually says is Enhanced IGRP integrates the capabilities of link-state protocols into distance vector protocols. That doesn't say it is link-state, it says that it has the capabilities of link-state - I assume they are referring to what Priscilla referred to; non-periodic, partial, bounded updates. JMcL - Forwarded by Jenny Mcleod/NSO/CSDA on 14/05/2002 09:42 am - Rick Sent by: [EMAIL PROTECTED] 14/05/2002 08:42 am Please respond to Rick To: [EMAIL PROTECTED] cc: Subject:Re: Is IGRP actually supported by other vendors? [7:43994] Is this part of a business decision process?: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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
Re: Is IGRP actually supported by other vendors? [7:43994]
Although, I don't entirely disagree with you I have not had any luck finding any documents on EIGRP that stated it was not a Hybrid Protocol or did not list enough Link-State qualities to include it as a partial Link-State Protocol. That is outside of one document by you. Rick - Original Message - From: Howard C. Berkowitz To: Rick ; Sent: Monday, May 13, 2002 8:35 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 6:42 PM -0400 5/13/02, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Abraham Lincoln once asked a fellow, If you call a horse's tail a leg, how many legs does a horse have? And the fellow answered ummm...five. Lincoln shook his head. No. Calling a tail a leg does not make it one. Just looking at the URL above, it's pointing to the introduction to internetworking, which is rarely updated and is not infrequently misleading or wrong. I suggest you look at current Cisco white papers on routing protocols, Garcia-Luna-Alceves' academic paper, any number of Networkers presentations, routing discussions in the IETF, etc. No one seriously uses the term hybrid, and there never was a technical definition of it. As opposed to Camelot being one shining moment, the use of hybrid protocol originated from a bubbling cauldron of spin doctoring from marketing, parroting by training, and perhaps a dark blessing by Sir Mordred. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44161t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 6:42 PM -0400 5/13/02, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Abraham Lincoln once asked a fellow, If you call a horse's tail a leg, how many legs does a horse have? And the fellow answered ummm...five. Lincoln shook his head. No. Calling a tail a leg does not make it one. Just looking at the URL above, it's pointing to the introduction to internetworking, which is rarely updated and is not infrequently misleading or wrong. I suggest you look at current Cisco white papers on routing protocols, Garcia-Luna-Alceves' academic paper, any number of Networkers presentations, routing discussions in the IETF, etc. No one seriously uses the term hybrid, and there never was a technical definition of it. As opposed to Camelot being one shining moment, the use of hybrid protocol originated from a bubbling cauldron of spin doctoring from marketing, parroting by training, and perhaps a dark blessing by Sir Mordred. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44163t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
EIGRP does use poison reverse, and that's more evidence of its distance-vector behavior. I think I have been excluded again. I wish the proctor would let me back in! :-() Priscilla At 12:15 AM 5/14/02, Michael L. Williams wrote: I agree with Kent. Although the link you (Rick) provided uses the word link-state, it uses it once in the opening and once in the summary... That's it! The fact is that one needs to analyze the protocol to see it's behavior... it may well have traits of this or that type of protocol but not be either one. I mean, really the categories of Distance-Vector and Link-State are just descriptions, not hard boundaries. Priscilla has made a convincing argument that EIGRP acts mostly as a Distance-Vector protocol. Although it has advanced features that may resemble those of a link-state protocol, that doesn't make it link-state. As she mentioned, Link-State means something very specific to mathematicians (where all of these magic algorithms come from... *not* network people)... Link-state machinesBut, again, as Kent says, if you disagree then lay out your arguments for people to read and decide... It's interesting to note that Distance-Vector protocols, because of their operation, require various things to help them prevent routing loops, like poison reverse and split-horizon. EIGRP uses split-horizon, but not poison reverse. Does that make it distance-vector? Not necessarily. But it doesn't mean it's not either =) (I love riding the fence.. hehe) Check out the following link, and compare what it says to EIGRP and see what you think. http://www.cs.bris.ac.uk/Teaching/Resources/COMS22100/AC/slides/lec8P.pdf Mike W. Kent Yu wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Rick, I think the bottom line is no matter who says what, we want to take a look where he/she is coming from. If after reading Priscilla's post closely and comparing OSPF/IS-IS to RIP/EIGRP/IGRP, you still disagree with Priscilla on this, please let us your arguments. Thanks Kent Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44168t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Is IGRP actually supported by other vendors? [7:43994]
At 4:25 PM -0400 5/13/02, Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. You make some interesting instructional points that I want to think about. Let me make some observations. No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. Poison reverse, split horizon and holddown are explained decently in the very readable RIP RFC. Unequal cost load balancing is increasingly deprecated; there are better ways to do traffic engineering. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, I'd argue that other than some similarities in commands and metrics, IGRP and EIGRP are completely different protocols. There is a trivial case of neighbor relationships in RIP, as a router with a RIP-enabled interface will suppress outgoing updates until it hears a RIP query from a router on the medium. That is a form of neighbor discovery. It is different from using a hello subprotocol to know if a neighbor is still alive. Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. and once one has supernetting and neighbor relationships in his or her belt, they can deal with OSPF area types and LSA's and the like. Hal Logan CCAI, CCDP, CCNP:Voice Network Specialist / Adjunct Faculty Computing Engineering Technology Manatee Community College -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44170t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Howard, for the life of me I am certain I recall a discussion like this a couple of years ago on Groupstudy, and that you verified that there was indeed an open IGRP standard out there somewhere. Perhaps you're thinking of the Rutgers Paper by Hedrick. Cisco made legal incantations that IGRP was proprietary and they would not allow detailed descriptions to be published, but, hypothetically speaking, if one were to be published, it would be identical to the Rutgers Paper. Cisco's position was sort of Rutgers Paper? We don't see any Rutgers Paper. can't find it in the archives, but as a collector of odd protocols, I am certain I recall correctly.. Chuck - Original Message - From: Howard C. Berkowitz Newsgroups: groupstudy.cisco Sent: Sunday, 12 May, 2002 10:01 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 11:42 PM -0400 5/12/02, nrf wrote: 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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? I don't know the specifics of the Nokia case. Cisco has, however, both supplied router blades running IOS on an OEM basis to vendors including Cabletron, and licensed a software port to DEC (IOS on DEC hardware -- Brouter 500) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44171t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Rick, Since you seem so certain, in what way is EIGRP a link-state protocol? What link-state attributes does it have? I haven't read all of the article at the link you've given, but I note that in the intro what it actually says is Enhanced IGRP integrates the capabilities of link-state protocols into distance vector protocols. That doesn't say it is link-state, it says that it has the capabilities of link-state - I assume they are referring to what Priscilla referred to; non-periodic, partial, bounded updates. JMcL - Forwarded by Jenny Mcleod/NSO/CSDA on 14/05/2002 09:42 am - Rick Sent by: [EMAIL PROTECTED] 14/05/2002 08:42 am Please respond to Rick To: [EMAIL PROTECTED] cc: Subject:Re: Is IGRP actually supported by other vendors? [7:43994] Is this part of a business decision process?: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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 mont
RE: Is IGRP actually supported by other vendors? [7:43994]
At 4:25 PM -0400 5/13/02, Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. You make some interesting instructional points that I want to think about. Let me make some observations. No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. Poison reverse, split horizon and holddown are explained decently in the very readable RIP RFC. Unequal cost load balancing is increasingly deprecated; there are better ways to do traffic engineering. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, I'd argue that other than some similarities in commands and metrics, IGRP and EIGRP are completely different protocols. There is a trivial case of neighbor relationships in RIP, as a router with a RIP-enabled interface will suppress outgoing updates until it hears a RIP query from a router on the medium. That is a form of neighbor discovery. It is different from using a hello subprotocol to know if a neighbor is still alive. Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. and once one has supernetting and neighbor relationships in his or her belt, they can deal with OSPF area types and LSA's and the like. Hal Logan CCAI, CCDP, CCNP:Voice Network Specialist / Adjunct Faculty Computing Engineering Technology Manatee Community College -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44178t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 4:41 PM -0400 5/13/02, Priscilla Oppenheimer wrote: At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. This is a confusion caused by Cisco marketing, partially because they associated update-only protocols with a hello subprotocol with link state. That's flatly wrong. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. Where link state uses algorithms based on Dijkstra's (which is getting aged and has been modified), first and second generation DV use Bellman-Ford. EIGRP uses Diffusing Update by JJ Garcia-Luna-Alceves, who continues to publish on even more advanced DV algorithms. JJ was not involved in Cisco's EIGRP implementation. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). The best descriptions of this are in Alex Zinin's new book on Cisco routing. It's also worth looking at JJ's papers, although they are heavy on the mathematical side. If anybody wants to start getting into the true theory of routing protocols, you'll need at least a general knowledge of graph and automata theory. This is typically an advanced undergraduate course in a CS program, but isn't impossible to learn on your own. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44179t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Although, I don't entirely disagree with you I have not had any luck finding any documents on EIGRP that stated it was not a Hybrid Protocol or did not list enough Link-State qualities to include it as a partial Link-State Protocol. That is outside of one document by you. Rick Find ONE technical, not marketing or a throwaway line in courseware, definition of what a hybrid protocol is. - Original Message - From: Howard C. Berkowitz To: Rick ; Sent: Monday, May 13, 2002 8:35 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 6:42 PM -0400 5/13/02, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Abraham Lincoln once asked a fellow, If you call a horse's tail a leg, how many legs does a horse have? And the fellow answered ummm...five. Lincoln shook his head. No. Calling a tail a leg does not make it one. Just looking at the URL above, it's pointing to the introduction to internetworking, which is rarely updated and is not infrequently misleading or wrong. I suggest you look at current Cisco white papers on routing protocols, Garcia-Luna-Alceves' academic paper, any number of Networkers presentations, routing discussions in the IETF, etc. No one seriously uses the term hybrid, and there never was a technical definition of it. As opposed to Camelot being one shining moment, the use of hybrid protocol originated from a bubbling cauldron of spin doctoring from marketing, parroting by training, and perhaps a dark blessing by Sir Mordred. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44189t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
It's probably insufficient to refer to the source of igrp without referring to the source for allegedly open standards terminology used to misdescribe routing protocols such as distance vector (hint: NOT cisco . . .). Then again, when referring to the source for IGRP, depending upon the aspect of the technology you are referring to, better choices to depict as the source of IGRP might include JJ Garcia-Luna-Aceves, Chuck Hedrick or Len Bosack. From Hedrick's report: This paper really should show Len Bosack of cisco Systems as co-author, and possibly should also list an unidentified lawyer at Townsend and Townsend. Most of the ideas behind IGRP are Len's. Anyway, none of them work for Cisco (and at least one was kicked out with extreme prejudice). While Cisco has a lot of say over what IGRP is and is not, they have no authority to say what entities are or are not in the set of all objects defined as distance vector routing protocols, precisely because they DO sell routing products. Granting them that authority is almost as inimical to a better understanding of the subject matter as letting them define the structure content of OSI layers. - Original Message - From: Rick To: Sent: Monday, May 13, 2002 6:42 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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 Rutge
RE: Is IGRP actually supported by other vendors? [7:43994]
At 4:25 PM -0400 5/13/02, Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. You make some interesting instructional points that I want to think about. Let me make some observations. No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. Poison reverse, split horizon and holddown are explained decently in the very readable RIP RFC. Unequal cost load balancing is increasingly deprecated; there are better ways to do traffic engineering. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, I'd argue that other than some similarities in commands and metrics, IGRP and EIGRP are completely different protocols. There is a trivial case of neighbor relationships in RIP, as a router with a RIP-enabled interface will suppress outgoing updates until it hears a RIP query from a router on the medium. That is a form of neighbor discovery. It is different from using a hello subprotocol to know if a neighbor is still alive. Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. and once one has supernetting and neighbor relationships in his or her belt, they can deal with OSPF area types and LSA's and the like. Hal Logan CCAI, CCDP, CCNP:Voice Network Specialist / Adjunct Faculty Computing Engineering Technology Manatee Community College -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44194t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Although, I don't entirely disagree with you I have not had any luck finding any documents on EIGRP that stated it was not a Hybrid Protocol or did not list enough Link-State qualities to include it as a partial Link-State Protocol. That is outside of one document by you. Rick Find ONE technical, not marketing or a throwaway line in courseware, definition of what a hybrid protocol is. - Original Message - From: Howard C. Berkowitz To: Rick ; Sent: Monday, May 13, 2002 8:35 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 6:42 PM -0400 5/13/02, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Abraham Lincoln once asked a fellow, If you call a horse's tail a leg, how many legs does a horse have? And the fellow answered ummm...five. Lincoln shook his head. No. Calling a tail a leg does not make it one. Just looking at the URL above, it's pointing to the introduction to internetworking, which is rarely updated and is not infrequently misleading or wrong. I suggest you look at current Cisco white papers on routing protocols, Garcia-Luna-Alceves' academic paper, any number of Networkers presentations, routing discussions in the IETF, etc. No one seriously uses the term hybrid, and there never was a technical definition of it. As opposed to Camelot being one shining moment, the use of hybrid protocol originated from a bubbling cauldron of spin doctoring from marketing, parroting by training, and perhaps a dark blessing by Sir Mordred. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44193t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 4:41 PM -0400 5/13/02, Priscilla Oppenheimer wrote: At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. This is a confusion caused by Cisco marketing, partially because they associated update-only protocols with a hello subprotocol with link state. That's flatly wrong. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. Where link state uses algorithms based on Dijkstra's (which is getting aged and has been modified), first and second generation DV use Bellman-Ford. EIGRP uses Diffusing Update by JJ Garcia-Luna-Alceves, who continues to publish on even more advanced DV algorithms. JJ was not involved in Cisco's EIGRP implementation. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). The best descriptions of this are in Alex Zinin's new book on Cisco routing. It's also worth looking at JJ's papers, although they are heavy on the mathematical side. If anybody wants to start getting into the true theory of routing protocols, you'll need at least a general knowledge of graph and automata theory. This is typically an advanced undergraduate course in a CS program, but isn't impossible to learn on your own. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44195t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Although, I don't entirely disagree with you I have not had any luck finding any documents on EIGRP that stated it was not a Hybrid Protocol or did not list enough Link-State qualities to include it as a partial Link-State Protocol. That is outside of one document by you. Rick Find ONE technical, not marketing or a throwaway line in courseware, definition of what a hybrid protocol is. - Original Message - From: Howard C. Berkowitz To: Rick ; Sent: Monday, May 13, 2002 8:35 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] At 6:42 PM -0400 5/13/02, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Abraham Lincoln once asked a fellow, If you call a horse's tail a leg, how many legs does a horse have? And the fellow answered ummm...five. Lincoln shook his head. No. Calling a tail a leg does not make it one. Just looking at the URL above, it's pointing to the introduction to internetworking, which is rarely updated and is not infrequently misleading or wrong. I suggest you look at current Cisco white papers on routing protocols, Garcia-Luna-Alceves' academic paper, any number of Networkers presentations, routing discussions in the IETF, etc. No one seriously uses the term hybrid, and there never was a technical definition of it. As opposed to Camelot being one shining moment, the use of hybrid protocol originated from a bubbling cauldron of spin doctoring from marketing, parroting by training, and perhaps a dark blessing by Sir Mordred. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44197t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Is IGRP actually supported by other vendors? [7:43994]
Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. This is of course natural, but have you ever wandered how it feels for those who learn it this way to force their mindsets into classful thinking? Marko. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44198t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Is IGRP actually supported by other vendors? [7:43994]
At 4:25 PM -0400 5/13/02, Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. You make some interesting instructional points that I want to think about. Let me make some observations. No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. Poison reverse, split horizon and holddown are explained decently in the very readable RIP RFC. Unequal cost load balancing is increasingly deprecated; there are better ways to do traffic engineering. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, I'd argue that other than some similarities in commands and metrics, IGRP and EIGRP are completely different protocols. There is a trivial case of neighbor relationships in RIP, as a router with a RIP-enabled interface will suppress outgoing updates until it hears a RIP query from a router on the medium. That is a form of neighbor discovery. It is different from using a hello subprotocol to know if a neighbor is still alive. Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. and once one has supernetting and neighbor relationships in his or her belt, they can deal with OSPF area types and LSA's and the like. Hal Logan CCAI, CCDP, CCNP:Voice Network Specialist / Adjunct Faculty Computing Engineering Technology Manatee Community College -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44200t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 06:42 PM 5/13/02, Rick wrote: Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm Nope, the source is wrong too. I know Cisco likes to use that silly term and I suppose they can if they want to. But it's misleading. EIGRP does not have link-state behavior. Did you look up what that actually means on Google? You'll find lots of information on the actual computer-science meaning for the term. It's pretty cool. You have to remember that Cisco came out with EIGRP during a time of political/marketing battles about which was better, distance-vector versus link-state. That might explain their silly hybrid thing, but it's technically not accurate and the more advanced exams won't make you know it (hopefully)! I myself am not a fan Lammle, but on this one he is right No, he's not. Although I know he is just quoting some Cisco material, so what can you expect? and you are wrong and YES I said you are wrong! Wouldn't be the first time, but I'm not wrong in this case. EIGRP is as much Link-State as it is Distance Vector. Nonsense. In what way is it link-state? Try to actually convince me! ;-) Priscilla Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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
Re: Is IGRP actually supported by other vendors? [7:43994]
It's probably insufficient to refer to the source of igrp without referring to the source for allegedly open standards terminology used to misdescribe routing protocols such as distance vector (hint: NOT cisco . . .). Then again, when referring to the source for IGRP, depending upon the aspect of the technology you are referring to, better choices to depict as the source of IGRP might include JJ Garcia-Luna-Aceves, Chuck Hedrick or Len Bosack. From Hedrick's report: This paper really should show Len Bosack of cisco Systems as co-author, and possibly should also list an unidentified lawyer at Townsend and Townsend. Most of the ideas behind IGRP are Len's. Anyway, none of them work for Cisco (and at least one was kicked out with extreme prejudice). While Cisco has a lot of say over what IGRP is and is not, they have no authority to say what entities are or are not in the set of all objects defined as distance vector routing protocols, precisely because they DO sell routing products. Granting them that authority is almost as inimical to a better understanding of the subject matter as letting them define the structure content of OSI layers. - Original Message - From: Rick To: Sent: Monday, May 13, 2002 6:42 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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 Rutge
Re: Is IGRP actually supported by other vendors? [7:43994]
It's probably insufficient to refer to the source of igrp without referring to the source for allegedly open standards terminology used to misdescribe routing protocols such as distance vector (hint: NOT cisco . . .). Then again, when referring to the source for IGRP, depending upon the aspect of the technology you are referring to, better choices to depict as the source of IGRP might include JJ Garcia-Luna-Aceves, Chuck Hedrick or Len Bosack. I don't think JJ ever worked for Cisco. He developed the DUAL algorithm at Stanford Research Institute, which licensed it to Cisco. JJ is now at USC. He has said publicly that he had nothing to do with the EIGRP implementation and his current research has produced better algorithms. Bellman-Ford, like Dijkstra, originated from mathematical research not strictly related to routing. Base Algorithm Protocol -- Bellman-Ford RIP, IGRP, RTMP, Novell RIP DUAL EIGRP Dijkstra ISIS, OSPF, Novell NLSP, PNNI Path vector BGP From Hedrick's report: This paper really should show Len Bosack of cisco Systems as co-author, and possibly should also list an unidentified lawyer at Townsend and Townsend. Most of the ideas behind IGRP are Len's. Anyway, none of them work for Cisco (and at least one was kicked out with extreme prejudice). While Cisco has a lot of say over what IGRP is and is not, they have no authority to say what entities are or are not in the set of all objects defined as distance vector routing protocols, precisely because they DO sell routing products. Granting them that authority is almost as inimical to a better understanding of the subject matter as letting them define the structure content of OSI layers. - Original Message - From: Rick To: Sent: Monday, May 13, 2002 6:42 PM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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,
RE: Is IGRP actually supported by other vendors? [7:43994]
At 7:04 AM -0400 5/14/02, Marko Milivojevic wrote: Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. This is of course natural, but have you ever wandered how it feels for those who learn it this way to force their mindsets into classful thinking? Marko. First, not everyone needs to consider classful thinking, other than on old certification exams. I developed this teaching method while giving a series of courses to a major ISP, which, of course, only uses classless protocols. Second, I do describe classful addressing as a special case, with enforced aggregation to major network natural masks at interfaces between different major networks. Students just think of /8, /16, and /24 with restricted subnet masks and no supernetting, rather than class A/B/C (although they are taught to recognize those terms). Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44215t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 4:41 PM -0400 5/13/02, Priscilla Oppenheimer wrote: At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. This is a confusion caused by Cisco marketing, partially because they associated update-only protocols with a hello subprotocol with link state. That's flatly wrong. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. Where link state uses algorithms based on Dijkstra's (which is getting aged and has been modified), first and second generation DV use Bellman-Ford. EIGRP uses Diffusing Update by JJ Garcia-Luna-Alceves, who continues to publish on even more advanced DV algorithms. JJ was not involved in Cisco's EIGRP implementation. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). The best descriptions of this are in Alex Zinin's new book on Cisco routing. It's also worth looking at JJ's papers, although they are heavy on the mathematical side. If anybody wants to start getting into the true theory of routing protocols, you'll need at least a general knowledge of graph and automata theory. This is typically an advanced undergraduate course in a CS program, but isn't impossible to learn on your own. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44217t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Is IGRP actually supported by other vendors? [7:43994]
Howard, thanks for your input. Comments inline... Hal -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 7:22 AM To: [EMAIL PROTECTED] Subject: RE: Is IGRP actually supported by other vendors? [7:43994] At 4:25 PM -0400 5/13/02, Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. You make some interesting instructional points that I want to think about. Let me make some observations. No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. From this statement I'm inferring that you don't consider EIGRP to be a modern protocol? If so, I would concede that it's not as scalable as OSPF or IS-IS. But it's still deployed in networks, and anyone going through cisco's certification program has to learn it. Or am I missing something on EIGRP's calculation of a metric based on bandwidth and delay? At any rate, I haven't had enough caffeine today to wrestle with intraarea, interarea, and external routes as part of a composite metric. I suppose if someone really wanted to they could try to argue that External Type 1 routes qualify as a composite metric, but I think even that's pushing it. Poison reverse, split horizon and holddown are explained decently in the very readable RIP RFC. Agreed. Whenever possible I like to demonstrate protocols in action, rather than tell a student to take my word for it, or even take an RFC's word for it. Besides, I almost have to threaten physical violence before I can get a student to read an RFC. (Considering that I work for a state-funded community college, physical threats are usually frowned upon) RIP does work nicely along those lines; if a student does some debugging and sees an advertisement go out with a hop count of 16, usually a connection gets made to the idea of advertising a network as unreachable, and viola. Poison Reverse is now associated with a network the student has set up, and seen in action, rather than a paragraph from a textbook or an RFC. The benefit of demonstrating the same concepts again using IGRP is simple reinforcement. Unequal cost load balancing is increasingly deprecated; there are better ways to do traffic engineering. That's why I don't spend a lot of time covering it. I do however have an obligation to at least pay lip service to it, enough to ensure that students associate the variance command with UCLB. When Cisco takes it off the cert exams, I'll stop teaching it. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, I'd argue that other than some similarities in commands and metrics, IGRP and EIGRP are completely different protocols. This is conjecture on my part, as I won't teach my first CCNP class until January... but it seems to me that when put in a class where they have to learn the basics of EIGRP, OSPF, and BGP, students are going to focus first and foremost on the configuration commands. Considering that the only difference between the basic configuration process for igrp and for ip eigrp is the addition of the mask option after the network command (along with the addition of a vowel) I believe that will free up some CPU cycles so that students can focus on DUAL, multiple topology tables, summary addresses, feasible successors, and other new concepts. There is a trivial case of neighbor relationships in RIP, as a router with a RIP-enabled interface will suppress outgoing updates until it hears a RIP query from a router on the medium. That is a form of neighbor discovery. It is different from using a hello subprotocol to know if a neighbor is still alive. See, I call that a useful comparison. When I field questions, I'd say at least half of them boil down to how does this compare to what I already know? Personally, when I'm teaching beginning IP, I start with binary, and then VLSM/CIDR becomes a natural idea. I then introduce dotted decimal, and only as an afterthought mention classes. Works well whenever I've tried it. I very rarely have the luxury of teaching beginning IP. Usually
Re: Is IGRP actually supported by other vendors? [7:43994]
Hal, I agree. IGRP is a valuable teaching tool. Much like we used to teach BASIC to students before introducing more advanced programming languages. Done correctly, you could even teach Top Down, Structured Progamming techniques with BASIC. The same concept is true with IGRP. Prof. Tom Lisa, CCAI Community College of Southern Nevada Cisco ATC/Regional Networking Academy Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, and once one has supernetting and neighbor relationships in his or her belt, they can deal with OSPF area types and LSA's and the like. Hal Logan CCAI, CCDP, CCNP:Voice Network Specialist / Adjunct Faculty Computing Engineering Technology Manatee Community College -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 1:27 PM To: [EMAIL PROTECTED] 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. W
RE: Is IGRP actually supported by other vendors? [7:43994]
At 12:35 PM -0400 5/14/02, Logan, Harold wrote: Howard, thanks for your input. Comments inline... Hal -Original Message- From: Howard C. Berkowitz [mailto:[EMAIL PROTECTED]] Sent: Tuesday, May 14, 2002 7:22 AM To: [EMAIL PROTECTED] Subject: RE: Is IGRP actually supported by other vendors? [7:43994] At 4:25 PM -0400 5/13/02, Logan, Harold wrote: You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. You make some interesting instructional points that I want to think about. Let me make some observations. No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. From this statement I'm inferring that you don't consider EIGRP to be a modern protocol? IGRP, no. EIGRP, reasonably modern, but with less motivation for its use than there once was. For example, its ability to handle Apple and Novell was useful while they ran ships-in-the-night, but with desktop protocols moving to native IP, that's increasingly irrelevant. It's generally less resource intensive than link state protocols, but processor costs keep coming down. Carriers don't want to use it because they don't understand the internals, and they do have multivendor interoperability requirements. If so, I would concede that it's not as scalable as OSPF or IS-IS. But it's still deployed in networks, and anyone going through cisco's certification program has to learn it. Or am I missing something on EIGRP's calculation of a metric based on bandwidth and delay? Earlier in this thread, someone used the phrase it's true at this level. One of the things that's true at tbe real level is metric is not the only factor used in route selection, and often is far less important than prefix length, topological relationships, etc. OSPF and ISIS relative preference for intra-area routes is not a metric, but is more important in route selection than metric. Composite metrics simply aren't as important as was once thought they'd be. The overall trend of routing, combined with traffic engineering, is to move a lot of the load management, etc., to MPLS. MPLS uses routing protocols to find the paths that it can set up, then uses RSVP-TE or LDP to set up the paths. Loosely speaking, policy-routing like constructs assign QoS critical traffic to traffic engineered LSPs. At any rate, I haven't had enough caffeine today to wrestle with intraarea, interarea, and external routes as part of a composite metric. I suppose if someone really wanted to they could try to argue that External Type 1 routes qualify as a composite metric, but I think even that's pushing it. Again, there's a tremendous tendency to fixate on one concept such as metric, and assume that all route selection depends on it. Poison reverse, split horizon and holddown are explained decently in the very readable RIP RFC. Agreed. Whenever possible I like to demonstrate protocols in action, rather than tell a student to take my word for it, or even take an RFC's word for it. Besides, I almost have to threaten physical violence before I can get a student to read an RFC. (Considering that I work for a state-funded community college, physical threats are usually frowned upon) RIP does work nicely along those lines; if a student does some debugging and sees an advertisement go out with a hop count of 16, usually a connection gets made to the idea of advertising a network as unreachable, and viola. Poison Reverse is now associated with a network the student has set up, and seen in action, rather than a paragraph from a textbook or an RFC. The benefit of demonstrating the same concepts again using IGRP is simple reinforcement. Unequal cost load balancing is increasingly deprecated; there are better ways to do traffic engineering. That's why I don't spend a lot of time covering it. I do however have an obligation to at least pay lip service to it, enough to ensure that students associate the variance command with UCLB. When Cisco takes it off the cert exams, I'll stop teaching it. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need
RE: Is IGRP actually supported by other vendors? [7:43994]
Howard C. Berkowitz 5/14/02 11:46:39 AM No modern routing protocol uses composite metrics, in the sense that a numerical value is computed from several factors. I don't know if you'd consider route preference (e.g., OSPF intraarea over interarea over external) to be composite; I don't. From this statement I'm inferring that you don't consider EIGRP to be a modern protocol? I must be misunderstanding this statement, as well, and I'm wondering if it's because the word composite might have a different meaning in this context. Howard seems to stick with 'complex metric' instead of composite. Howard, is there a subtlety here that we're missing? I was under the impression that the (E)IGRP metric was a composite because it took into account multiple metrics when calculating a final metric. Even though they don't use all available factors they do still use bandwidth and delay. Doesn't that qualify? Or, are we being imprecise by using the word composite in this context in the first place? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44261t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44007t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
It's probably worth distinguishing between IGRP the rest of the set of proprietary cisco technologies, since they are more than eager to distance themselves from any of the features of IGRP that were overridden by EIGRP. As for impossibility, that's probably a question of the skill set possessed by the technical folk charged with reverse engineering the IOS code. Few vendors are bold enough to claim such interoperability without a formal exchange between their legal representation whomever performs that role for cisco. - Original Message - From: nrf To: Sent: Monday, May 13, 2002 4:02 AM Subject: Re: Is IGRP actually supported by other vendors? [7:43994] 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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44015t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
nrf wrote: vendor compatibility between some other vendor and Cisco. For example, does anybody know of another vendor that supports, say, EIGRP? Or CDP? Now you I know that Netscout probes are identified as CDP neighbors. Not sure that I remember seeing anything else identified as such though. Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44019t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 4:02 AM -0400 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? I'd be very surprised if another vendor simply reverse-engineered IGRP, because Cisco has some patents on it. Given how aggressive they are in protecting their trademarks, I'd be amazed if their legal staff wouldn't pounce on someone doing so. When it was first becoming obvious that RIP wouldn't scale to the networks then under development, Cisco very reasonably started developing IGRP. It's generally believed that they offered it to the IETF as a potential standard, but other vendors did not want to let something become standard with Cisco's experience base in place. So, the IETF effort for a second-generation standard protocol was politically motivated to be non-IGRP, and would up being OSPF. ISIS existed at the time, but at that point, there were political wars between the OSI and IETF people. While I haven't seen an IETF proposal, I have the impression that Cisco is being much more open about licensing CDP (although obviously it will have to be called something else as a standard), or using it as the base for some other protocol. It does do something generally useful. There's certainly precedent, because HSRP really derives from a DEC protocol (whose name escapes me) that was used in VAXclusters, and VRRP is very, very close to HSRP but multivendor. -- What Problem are you trying to solve? ***send Cisco questions to the list, so all can benefit -- not directly to me*** Howard C. Berkowitz [EMAIL PROTECTED] Chief Technology Officer, GettLab/Gett Communications http://www.gettlabs.com Technical Director, CertificationZone.com http://www.certificationzone.com retired Certified Cisco Systems Instructor (CID) #93005 Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44026t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44065t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Lamme's CCNA study guide states that the courde and exam only covers distance-vector routing protocols (RIP and IGRP). - 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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44081t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Priscilla Oppenheimer http://www.priscilla.com Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44086t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: Is IGRP actually supported by other vendors? [7:43994]
You're right about IGRP still being listed on the CCNA objectives. While I've sometimes found it frustrating to teach an outdated protocol, IGRP is useful as a teaching tool. With IGRP you can easily demonstrate the concept of composite metrics, poison reverse, holddown timers, split horizon, and unequal-cost load balancing, but you don't have multicast updates, neighbor relationships, incremental updates, and VLSM's adding to the confusion. If EIGRP replaces IGRP on the CCNA, then hopefully the certification team will draw a clear line indicating which features of eigrp will be tested and which ones won't. The way things are right now, IGRP makes for a smooth transition from the CCNA to the CCNP Routing exam. Someone who understands IGRP doesn't need to reinvent the wheel to learn EIGRP, and once one has supernetting and neighbor relationships in his or her belt, they can deal with OSPF area types and LSA's and the like. Hal Logan CCAI, CCDP, CCNP:Voice Network Specialist / Adjunct Faculty Computing Engineering Technology Manatee Community College -Original Message- From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] Sent: Monday, May 13, 2002 1:27 PM To: [EMAIL PROTECTED] 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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44101t=43994 -- FAQ, list archives, and subscription info: http://www.groups
Re: Is IGRP actually supported by other vendors? [7:43994]
At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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 pro
Re: Is IGRP actually supported by other vendors? [7:43994]
Like DLSw, token ring RIF calculation, NLSP, and a few other obscure an obsolete technologies, IGRP will no doubt continue to have a place in Cisco examinations just because it provides one heck of a way to screw you, the test taker. Chuck ( been there, done in by that ) Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... 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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? Priscilla Oppenheimer http://www.priscilla.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44118t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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
Re: Is IGRP actually supported by other vendors? [7:43994]
Rick, I think the bottom line is no matter who says what, we want to take a look where he/she is coming from. If after reading Priscilla's post closely and comparing OSPF/IS-IS to RIP/EIGRP/IGRP, you still disagree with Priscilla on this, please let us your arguments. Thanks Kent Rick wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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
Re: Is IGRP actually supported by other vendors? [7:43994]
Rick, I think the bottom line is no matter who says what, we want to take a look where his/her coming from. If after reading Priscilla's post closely and comparing OSPF/IS-IS to RIP/EIGRP/IGRP, you still disagree with Priscilla, please show us your arguments. Thanks Kent Rick wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Priscilla, I hate to differ with you on this Hybrid or not but the source says it is considered a Hybrid routing Protocol. check the link for yourself http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/en_igrp.htm I myself am not a fan Lammle, but on this one he is right and you are wrong and YES I said you are wrong! EIGRP is as much Link-State as it is Distance Vector. Rick Priscilla Oppenheimer wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... At 04:13 PM 5/13/02, Mike Mandulak wrote: Lammle refers to EIGRP as being a Hybrid of distance-vector and link state. That's wrong. EIGRP is not link-state in any way. EIGRP calculates a flat routing table that lists networks, distance, and next hop (distance vectors). If the list contains multiple entries for a destination (because there are multiple ways to reach the destination), the entries are sorted by metric and the one with the lowest metric is selected. This is very different than how a link-state protocol functions. A link-state routing protocol creates a mathematical graph that depicts the network. A link-state protocol implements a sophisticated process, called the Dijkstra algorithm, to determine the shortest path to all points in the graph when the nodes and links in the graph are known. Link-state has a specific meaning to computer scientists. You'll find a lot of good stuff about it if you search with Google. A lot of it is not related to routing protocols. EIGRP does have some features that make it different from other distance-vector protocols. Although EIGRP still sends vectors with distance information, the updates are non-periodic, partial, and bounded. Non-periodic means that updates are sent only when a metric changes rather than at regular intervals. Partial means that updates include only routes that have changed, not every entry in the routing table. Bounded means that updates are sent only to affected routers. These behaviors mean that EIGRP uses very little bandwidth. EIGRP also determines a feasible successor, which other distance-vector protocols don't do. Its complex metric is also a feature not found in many other distance-vector algorithms, (except IGRP of course). Please do not send messages to me directly, especially not to quote Lammle CCNA fluff. Priscilla 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 mess
Re: Is IGRP actually supported by other vendors? [7:43994]
I agree with Kent. Although the link you (Rick) provided uses the word link-state, it uses it once in the opening and once in the summary... That's it! The fact is that one needs to analyze the protocol to see it's behavior... it may well have traits of this or that type of protocol but not be either one. I mean, really the categories of Distance-Vector and Link-State are just descriptions, not hard boundaries. Priscilla has made a convincing argument that EIGRP acts mostly as a Distance-Vector protocol. Although it has advanced features that may resemble those of a link-state protocol, that doesn't make it link-state. As she mentioned, Link-State means something very specific to mathematicians (where all of these magic algorithms come from... *not* network people)... Link-state machinesBut, again, as Kent says, if you disagree then lay out your arguments for people to read and decide... It's interesting to note that Distance-Vector protocols, because of their operation, require various things to help them prevent routing loops, like poison reverse and split-horizon. EIGRP uses split-horizon, but not poison reverse. Does that make it distance-vector? Not necessarily. But it doesn't mean it's not either =) (I love riding the fence.. hehe) Check out the following link, and compare what it says to EIGRP and see what you think. http://www.cs.bris.ac.uk/Teaching/Resources/COMS22100/AC/slides/lec8P.pdf Mike W. Kent Yu wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... Rick, I think the bottom line is no matter who says what, we want to take a look where he/she is coming from. If after reading Priscilla's post closely and comparing OSPF/IS-IS to RIP/EIGRP/IGRP, you still disagree with Priscilla on this, please let us your arguments. Thanks Kent Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=44134t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
At 11:42 PM -0400 5/12/02, nrf wrote: 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 box lying around that I can actually experiment with. Can anyone confirm whether this is true and whether it provides complete interoperability with Cisco? I don't know the specifics of the Nokia case. Cisco has, however, both supplied router blades running IOS on an OEM basis to vendors including Cabletron, and licensed a software port to DEC (IOS on DEC hardware -- Brouter 500) Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=43996t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: Is IGRP actually supported by other vendors? [7:43994]
Comments inline... --- Howard C. Berkowitz wrote: I don't know the specifics of the Nokia case. Cisco has, however, both supplied router blades running IOS on an OEM basis to vendors including Cabletron, and licensed a software port to DEC (IOS on DEC hardware -- Brouter 500) And the blade for the Synoptics 3000 chassis... __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=43997t=43994 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
