At 10:12 PM +0000 1/10/03, Doug S wrote:
>I liked the comment and definitely agree that some of the authors of Cisco
>training material should be named and publicly humiliated, although the
>sheer volume of mistakes could make this a somewhat overwhelming task for
>the public doing the humiliating. Still, I want to add my opinion that Cisco
>documentation and training material is of a lot higher quality a lot of
>what's out there, not to name names like MS Press or anything.
I'm the last person to be an apologist for some of the documentation,
but fairness says there are a couple of things to consider.
1. Most Cisco documentation is what might be called "performance skills"
based rather than "cognitive" or "design". There's very little
information about alternative solutions, or other things that I
think of as network architecture. Historically, CID (which
originally
was an internal course) was the only course that went into tradeoffs,
although there are a good many more Cisco-only courses that do.
2. Since the market crash, there's been much less marketability for
books
that deal with design rather than cookbook or certification-cram
content. It's unfortunate -- corporate "economies" are equating
configuration skills with design skills.
3. It's almost impossible to keep any kind of general documentation
updated on all the permutations of platforms, releases, and bugs.
Conceptually, I suppose, Cisco could develop a context-sensitive
living hyperdocument that links basic documentation, release notes
and bug reports, etc., and have a much better support product, but
that would still be support rather than tradeoff oriented.
>
>The reason I blindly accepted and posted that particular quote is because it
>DOES match my personal experience, which, I admit is considerably less than
>the other posters in this thread. The only experience I have is in a lab on
>2500's and 2600's running something around IOS 12.1(T).
I'm sort of laughing and crying, thinking of my most dramatic
classroom bug. I was teaching a private ACRC class for MCI, with a
mixture of 2500, 4000, and 4500 routers, on, IIRC, IOS 11.0 or so. I
had just finished showing GRE for IP, and someone asked a question
about running IPX over the same tunnel as the IP. I _know_ this
works.
So, I said, "no problem". I switched a router console to the
projector, added an IPX network to one end of the tunnel, and it went
in just fine. Next, I switched to the other router. No sooner had I
finished typing IPX network AAAA, did both routers go into the most
incredible crash mode I have ever seen. They dropped into ROMMON, and
then kept cycling back to the start of boot, never giving me keyboard
control. Powering them on and off brought back sanity, but I soon
found that this crash was reproducible on 4000's and 4500's, but not
2500's. The TRULY weird thing is that when I left a router running
overnight in its boot loop, it eventually stabilized and gave console
control -- but still would crash if I configured IPX tunneling over
GRE.
>
>I also want to point of that this behavior of only overloading the first
>address in the pool sounds like exactly what the original poster is
>experiencing. The fact that Emilia's and my experience contradicts Peter's
>and TLaWR makes me think that there are differences in how this works on
>different platforms, as TJ suggests.
There _might_ be theoretical problems of load distribution here,
depending on how the address cached in other machines.
Source-destination hash is very good in most cases, but if you had
this configuration on both ends, everything would go over the same
link no matter how many interfaces you had. If the load balancing
were destination-based, it could get awful.
>
>I'd also like to hear people's opinions on why my solution is a "horrible"
>kludge, as opposed to just a plain old vanilla kludge.
Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=60857&t=60663
--------------------------------------------------
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html
Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]