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 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?" I like to explain DV protocols as "generations." 1st Generation (IP RIP): Periodic update/no hello, hop count metric, loop prevention with split horizon and holddown, loop detection with count to infinity. 2nd Generation (IGRP, IPX RIP): Periodic update/no hello, more complex metrics, loop prevention with split horizon and holddown, loop detection with count to infinity or other factors such as monotonically increasing metric. 3rd Generation (EIGRP) Update only/hello subprotocol, complex metric, loop prevention with DUAL, basically no requirement for loop detection because the computation is loop-free. > >> 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 by >the time I get ahold of a networking class they've already been >taught how to subnet using the 256 subtraction shortcut, and they've >only been taught how to subnet a class C address. So right off the >bat, I get people who've been taught how not to use binary, and who >have a mental block about subnetting anything other than a class C. >The first thing I do when I discuss IP addressing with a class is >(try to) tell them with a straight face that I'm too dumb to do the >256 subtraction, and from there we work on unlearning "IP subnetting >for dummies." I yell a lot that "good networks have no class!" I haven't yet had the opportunity to try Marxist dialectic about class warfare being the barrier to progress, but it's always a temptation. > >One of the downsides of teaching the networking academy classes for >an entire semester rather than doing 2 and 3 week classes is that >many of the students expect things to be spoon-fed to them, and >don't retain information as well as they might in a seminar format. >My experience has been that most beginning networkers need at least >2 solid exposures to binary numbering and IP subnetting before it >starts to sink in. > > > > >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 Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=44256&t=43994 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
