GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
Re: Load balancing & NAT [7:60663] posted 01/11/2003
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


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 abuse@xxxxxxxxxxxxxx