Mailing List Archive

1 2 3 4 5 6 7 8 9  View All
Re: Common operational misconceptions [ In reply to ]
On Fri, Feb 17, 2012 at 06:52, -Hammer- <bhmccie@gmail.com> wrote:
> Let me simplify that. If you are over 35 you know how to troubleshoot.
>
> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.

"Necessity is the mother of invention"

Long before there was a Grainger (and Home Depot) in
every city, and you could get parts shipped overnight,
one had to "make do", and "making do" meant being
able to figure things out to be able to "git r done"
with what you had on hand, or could figure out.

When working on my Grandfather's farm, I did not
look for work to do (actually, I looked for ways
not to do any work :-), but if the project required
pulling out the oxy-acetylene torch to cut and
weld something onto the tractor to get something
done, that is what you had to do, so you did it.
If the TV went on the blink (they all did then),
you opened up the back, looked for fried
components, and if one of the resistors was
smoking, you soldered in a replacement. Or
you took the tubes down to the local drugstore
and tested them. Even if you had no idea what
you were doing, you were willing (and expected)
to give it a shot, and try to fix it. More often
than not you learned something along the way,
even if it took hours to figure it out (and had to
repair your repair a few times :-). For those
without the capabilities, you took it to the shop,
where someone else did the troubleshooting
and repair.

Along the line, the costs of technicians to
do that type of work started to exceed the
cost of simply replacing the entire unit
(how many people remember when going
to the auto dealer that the cost of the parts
far exceeded the cost of the labor? Now it
is the other way around). Troubleshooting
became a lost art. "Swap 'til you drop"
became the mantra. It became the cost
effective way to do repairs.

There are advantages to the new way of
disposable devices, but almost no one
knows how they work anymore, and they
do not care to know. The members of this
list are likely to be sufficiently self selected
to be in the minority of actually wanting to
know.

There is a (small) backlash of people who
are trying to get back into the world of
actually building things, and understanding
how they work (popularized by such things
as Make magazine, and Maker Faires).

Gary
Re: Common operational misconceptions [ In reply to ]
On Fri, Feb 17, 2012 at 08:46:02AM -0800, Mike Lyon wrote:
> Sent from my iPhone
>
> On Feb 17, 2012, at 7:48, Jack Bates <jbates@brightok.net> wrote:
>
> >
> >
> > On 2/17/2012 9:18 AM, Steve Clark wrote:
> >> Having worked with many people over the last 40 years, the good trouble
> >> shooters understood how things
> >> were suppose to work. This helps immeasurably in determining where to
> >> start looking.
> >>
> >
> > Ran into this not too long ago with a transport problem. The behavior I was seeing was indicative of the transport not stripping their outer tag. They put wireshark on a windows laptop and sent me the traffic captures. While I didn't know that M$ decided to do something silly like removing a single tag, all indicators were that the M$ stack "fixed" whatever was broken prior to wireshark. We took a capture from another device and proved the problem.
> >
> > Which is a common transport problem I often see, "Our configuration looks right, it must be on your end."
>
> If i had a dollar for everytime i've heard that from a telco, i'd be a
> rich man...

That and "I'm getting a good ping response here" while I've got the cable
at my end unplugged from the equipment.

--
Mike Andrews, W5EGO
mikea@mikea.ath.cx
Tired old sysadmin
Re: Common operational misconceptions [ In reply to ]
I often struggle with the concept of teaching someone how to
troubleshoot. We have young guys coming in all the time and it is
often an area in which they need to hone their skills. I found this
article a while back and I keep it bookmarked, its the best article
I've seen that lays it all out pretty clearly.

http://packetlife.net/blog/2010/mar/10/the-science-of-network-troubleshooting/

-Marcel

I'm guessing, but I believe the author would fall into the under 35 category ;-)

On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- <bhmccie@gmail.com> wrote:
> Mario,
>    I was kinda having fun and kinda not. My point is that the 40-50 year
> olds that were doing this 30 years ago grew up understanding things in
> order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those
> confused). Hex. etc. Move on to the OSI model and it's the same thing.
> Voltage. Amplitude. Binary. etc. I think that this generation that I'm
> referring to is a great generation because we were at the beginning of the
> Internet blooming. There are folks on this forum that go back further. Into
> DARPA. Before DARPA was just chapter 1 one every single Cisco Press book.
> They have a unique understanding of the layers. I had that understanding in
> my 20s. The technology is so complicated these days that many folks miss
> those fundamentals and go right into VSS on the 6500s or MPLS over Juniper.
> In the end, it all comes in time.
>
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:12 AM, Mario Eirea wrote:
>>
>> Well, I will argue this. I think the important factor in any
>> troubleshooting is having a real understanding of how the system works. That
>> is, how different things interact with each others to achieve a specific
>> goal. The biggest problem I see is that many people understand understand
>> the individual parts but when it comes to understanding the system as a
>> whole they fall miserably short.
>>
>> A short example, probably not the best but the one that comes to mind
>> right now:
>>
>> Someone replaces a device on the network with a new one. They give it the
>> same IP address as the old device. They don't understand why the router cant
>> communicate with it at first and then starts working. The people
>> "understand" ARP, but cant correlate one event with another.
>>
>> I guess if your 35 you have seen this at least once and can fix it. But
>> what happens if you have never seen this problem or a related one? At this
>> point your going to have to really troubleshoot, not just go on experience.
>>
>> Mario Eirea
>> ________________________________________
>> From: -Hammer- [bhmccie@gmail.com]
>> Sent: Friday, February 17, 2012 9:52 AM
>> To: nanog@nanog.org
>> Subject: Re: Common operational misconceptions
>>
>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>
>> Yes, I'm going to get flamed. Yes, there are exceptions in both
>> directions.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>>>
>>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
>>> Graydon wrote:
>>>>
>>>> At the same time, it's shocking how many network people I come across
>>>> with no real grasp of even what OSI means by each layer, even if it's
>>>> only in theory.  Just having a grasp of that makes all the world of
>>>> difference when it comes to troubleshooting.  Start at layer 1 and work
>>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>>> physically connected? Are the link lights flashing? Can traffic route to
>>>> it, etc. etc.
>>>
>>> I wouldn't call it a "misconception", but I want to echo Paul's
>>> comment.  I would venture over 90% of the engineers I work with
>>> have no idea how to troubleshoot properly.  Thinking back to my own
>>> education, I don't recall anyone in highschool or college attempting
>>> to teach troubleshooting skills.  Most classes teach you how to
>>> build things, not deal with them when they are broken.
>>>
>>> The basic skills are probably obvious to someone who might design
>>> course material if they sat down and thought about how to teach
>>> troubleshooting.  However, there is one area that may not be obvious.
>>> There's also a group management problem.  Many times troubleshooting
>>> is done with multiple folks on the phone (say, customer, ISP and
>>> vendor).  Not only do you have to know how to troubleshoot, but how
>>> to get everyone on the same page so every possible cause isn't
>>> tested 3 times.
>>>
>>> I think all college level courses should include a "break/fix"
>>> exercise/module after learning how to build something, and much of that
>>> should be done in a group enviornment.
>>>
>>
>
Re: Common operational misconceptions [ In reply to ]
wasn't tv already tackled by dvb-iptv + multicast (oh wait, multicast,
that stuff that hardly ever globally works on ipv4 ;)

(yes, i'm that old that i even know what a tv was ;)

On Fri, 17 Feb 2012, Eugen Leitl wrote:

> On Fri, Feb 17, 2012 at 10:33:12AM -0500, Jay Ashworth wrote:
>> ----- Original Message -----
>>> From: "Ridwan Sami" <rms2176@columbia.edu>
>>
>>> There is no legitimate reason for a user to use BitTorrent (someone
>>> will probably disagree with this).
>>
>> Yeah, no.
>>
>> You've clearly never tried to download a Linux installer DVD.
>
> Nevermind that Bram Cohen is preparing to tackle TV with a
> BitTorrent-related protocol (no further details known yet).
>
RE: Common operational misconceptions [ In reply to ]
>
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with have no
> idea how to troubleshoot properly. Thinking back to my own education,
> I don't recall anyone in highschool or college attempting to teach
> troubleshooting skills. Most classes teach you how to build things,
> not deal with them when they are broken.

Look for people who grew up on a farm. They are used to figuring out how to fix things they haven't seen before and generally attempt to gain knowledge of the fundamental principles of how things work so they can apply those principles in a similar situation. For example, such a person may know enough about troubleshooting both gasoline and diesel engines and might have a better understanding of the underlying fundamentals of internal combustion engines to do a passable job troubleshooting something they have never seen before (air, fuel, timing). There is a certain APPROACH to troubleshooting that transcends various fields. Some naturally have a talent for it, others aren't so good at it. Such people might be better in a multi-vendor network when there is a problem. You can generally spot those people not by what they know, but by the quality of the questions they ask. They generally know what they want to accomplish or what they are looking for, but they might want to know how that is done with this particular vendor's command set or how this particular vendor processes traffic.

Some are natural designers, some are natural troubleshooters, some are natural documenters/support staff and they LIKE doing it. It takes all of those skills.

One important thing to keep in mind, too, is that by identifying the skills and natural talents of your line staff, you yourself are being a value multiplier to your organization. You are making best use of the resources that you have at your disposal and are improving the efficiency of the organization as an organic entity. So this benefits everyone in the entire organization, including you.
Re: Common operational misconceptions [ In reply to ]
On Fri, Feb 17, 2012 at 10:18:57AM -0500, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good trouble
> shooters understood how things
> were suppose to work. This helps immeasurably in determining where to start
> looking.

Don't forget that a lot of the best figure things out *while*
troubleshooting things they don't (yet) understand.

Give curious people good tools and interesting problems -- the rest will
sort itself out.
Re: Common operational misconceptions [ In reply to ]
Mark Grigsby <mark@pcinw.net> writes:

> Speaking in the context of configuring an ipsec tunnel..

Once upon a time:

Admin: "We need Port 50 and Port 51 for the tunnel!"
Me: "You mean IP protocol 50 and 51?"
Admin: "It the same! You have no clue!"

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------
RE: Common operational misconceptions [ In reply to ]
> BTW, I am a school board member who votes 1:8 often on things.... But
> let me give you a perspective, one of the board members called Golf an
> "Essential Life Skill." Maybe, but how about balancing a checkbook...
>
> Ralph Brandt
> Communications Engineer
> HP Enterprise Services

One of the best courses I ever had was in 9th grade math class when Mr. Martin taught us how to do taxes. And I mean even long forms with all the schedules and stuff for people who had investments and small sole proprietor businesses. It was a great practical math application, though it was mostly just arithmetic, some of the example cases were quite complex with estimated taxes, carrying forward losses from previous years, depreciation, etc. It gave us some context in which we could understand why we might need to learn math in real life and made taxes less daunting when we got older. Thanks, Mr. Martin!
Re: Common operational misconceptions [ In reply to ]
Mathias Wolkert <tias@netnod.se> writes:

> Autoneg. The old timers that don't trust it after a few decades of
> decent code. Or those that lock one side and expect the other to adjust
> to that.

Autoneg is black magic. Doesn't work. You have manually configure duplex
and speed on one side !!!!1!

SCNR

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------
Re: Common operational misconceptions [ In reply to ]
On Fri, 17 Feb 2012, Jens Link wrote:

> Mathias Wolkert <tias@netnod.se> writes:
>
>> Autoneg. The old timers that don't trust it after a few decades of
>> decent code. Or those that lock one side and expect the other to adjust
>> to that.

you are referring to ehh *kuch* certain internet exchanges *kuch* ? :P

auto mdi/mii breaks teh internets! oeh noes! (not on any equipment we've
owned for the past 15 years... funny how that works ;)

>
> Autoneg is black magic. Doesn't work. You have manually configure duplex
> and speed on one side !!!!1!
>
> SCNR
>
> Jens
> --
> -------------------------------------------------------------------------
> | Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
> | http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
> -------------------------------------------------------------------------
>
Re: Common operational misconceptions [ In reply to ]
On Feb 17, 2012, at 11:33 AM, John Osmon wrote:

On Fri, Feb 17, 2012 at 10:18:57AM -0500, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good trouble
> shooters understood how things
> were suppose to work. This helps immeasurably in determining where to start
> looking.

Don't forget that a lot of the best figure things out *while*
troubleshooting things they don't (yet) understand.

Give curious people good tools and interesting problems -- the rest will
sort itself out.

Quote I have hear over the years


"Problems are opportunities for learning - Just wish I was not doing so much learning some days...."
RE: Common operational misconceptions [ In reply to ]
> Long before there was a Grainger (and Home Depot) in every city, and
> you could get parts shipped overnight, one had to "make do", and
> "making do" meant being able to figure things out to be able to "git r
> done"
> with what you had on hand, or could figure out.
>
> When working on my Grandfather's farm, I did not look for work to do
> (actually, I looked for ways not to do any work :-), but if the project
> required pulling out the oxy-acetylene torch to cut and weld something
> onto the tractor to get something done, that is what you had to do, so
> you did it.

Yep, when looking for troubleshooters, look for people that grew up/worked on a farm.

I absolutely agree. They approach things from a completely different mindset.
Re: Common operational misconceptions [ In reply to ]
On 2/17/2012 12:00 PM, Gary Buhrmaster wrote:
> If the TV went on the blink (they all did then), you opened up the
> back, looked for fried components, and if one of the resistors was
> smoking, you soldered in a replacement. Or you took the tubes down to
> the local drugstore and tested them.

Wow... would be handy if Radio Shack stocked router modules and blades,
and chassis to test your suspect ones? :)

(Yes, remember the tube testers as well...)

Jeff
Re: Common operational misconceptions [ In reply to ]
I am grateful you have not used the hardware I have in the past 15 years.

I haven't seen anything recently not do it, but when interfacing with a customer who knows what old stuff they may be using.

Jared Mauch

On Feb 17, 2012, at 12:41 PM, Sven Olaf Kamphuis <sven@cb3rob.net> wrote:

> auto mdi/mii breaks teh internets! oeh noes! (not on any equipment we've owned for the past 15 years... funny how that works ;)
RE: Common operational misconceptions [ In reply to ]
>
> Wow... would be handy if Radio Shack stocked router modules and
> blades,
> and chassis to test your suspect ones? :)
>
> (Yes, remember the tube testers as well...)
>
> Jeff

Heh, that's been a notion I have had for a while. Opening an all-night shop somewhere in Silicon Valley that sold patch cords, memory sticks, disk drives, maybe even common router blades, optics modules, fans, etc. Sell it for a bit more margin than the going rate for the "day" shops and ONLY be open at night/early morning, say 7pm to 11am. Maybe do some "remote hands" work, too.

Fry's wanted $55 for a 1 meter LC-LC multi-mode patch cord yesterday at the store on Arques in Sunnyvale.
Re: Common operational misconceptions [ In reply to ]
In a message written on Fri, Feb 17, 2012 at 06:06:52PM +0000, George Bonser wrote:
> Heh, that's been a notion I have had for a while. Opening an all-night shop somewhere in Silicon Valley that sold patch cords, memory sticks, disk drives, maybe even common router blades, optics modules, fans, etc. Sell it for a bit more margin than the going rate for the "day" shops and ONLY be open at night/early morning, say 7pm to 11am. Maybe do some "remote hands" work, too.

I've repeatedly asked $BIG_COLO_PROVIDERS to offer a vending machine
in the lobby next to the one with sodas that sold Cat 5, Fiber,
SFP's, USB sticks, and so on. Even at a moderate margin I suspect it
would be quite profitable to them, and quite welcomed by customers who
show up in the middle of the night when nothing is open and need parts.

--
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
Re: Common operational misconceptions [ In reply to ]
----- Original Message -----
> From: "Mike Andrews" <mikea@mikea.ath.cx>

> > > Which is a common transport problem I often see, "Our
> > > configuration looks right, it must be on your end."
> >
> > If i had a dollar for everytime i've heard that from a telco, i'd be
> > a rich man...
>
> That and "I'm getting a good ping response here" while I've got the
> cable at my end unplugged from the equipment.

"The problem's leaving here fine!"

Cheers,
-- jra
--
Jay R. Ashworth Baylink jra@baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
RE: Common operational misconceptions [ In reply to ]
To find counterfeit they teach you what good money looks like. When you
are looking at a sniffer trace you are generally looking for something
that is not right.



Ralph Brandt
Communications Engineer
HP Enterprise Services
Telephone +1 717.506.0802
FAX +1 717.506.4358
Email Ralph.Brandt@pateam.com
5095 Ritter Rd
Mechanicsburg PA 17055

-----Original Message-----
From: Scott Helms [mailto:khelms@ispalliance.net]
Sent: Friday, February 17, 2012 11:24 AM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

On 2/17/2012 10:18 AM, Steve Clark wrote:
> I agree with this 100%.
>
> Having worked with many people over the last 40 years, the good
> trouble shooters understood how things
> were suppose to work. This helps immeasurably in determining where to
> start looking.
>

This is dead on and why I always start classes with a refresher on the
OSI model. While the model isn't perfect it lets technicians and
engineers construct a reasonable model of how things *ought* to be
working. While you certainly will run into devices that bend or even
break the rules (sometimes for good reasons) its much easier to
understand the exceptions if you know the normal operation for a
repeater, bridge, or router.

--
Scott Helms
Vice President of Technology
ISP Alliance, Inc. DBA ZCorum
(678) 507-5000
--------------------------------
http://twitter.com/kscotthelms
--------------------------------
Re: Common operational misconceptions [ In reply to ]
On 02/17/2012 04:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and work
>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>> physically connected? Are the link lights flashing? Can traffic route to
>> it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with
> have no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to
> build things, not deal with them when they are broken.
The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
troubleshooting. Not sure if they still do, or if trainers even bother
to mention it (mine did back when I did it several years ago)

> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how
> to get everyone on the same page so every possible cause isn't
> tested 3 times.
Never trust what you can't prove yourself, that includes vendors and
customers. Every now and then I forget this and find hours later that
I've wasted a whole bunch of time because I trusted when someone said
something that it actually was the case. It's really often better to
test something a third time even if Vendor and Customer tell you
something is a particular way.

>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of that
> should be done in a group enviornment.
>
Definitely. I've learnt more in my time from breaking things than I've
ever learnt setting them up; however the education system is focused on
breadth of knowledge, not depth. Students are expected to be able to
regurgitate ridiculous amounts of facts and figures, so that they pass
standardised tests, not understand how to actually use them.

Paul
Re: Common operational misconceptions [ In reply to ]
Leo Bicknell <bicknell@ufp.org> writes:

> I've repeatedly asked $BIG_COLO_PROVIDERS to offer a vending machine
> in the lobby next to the one with sodas that sold Cat 5, Fiber,
> SFP's, USB sticks, and so on.

Hmm.....

http://gearomat.com/

Jens
--
-------------------------------------------------------------------------
| Foelderichstr. 40 | 13595 Berlin, Germany | +49-151-18721264 |
| http://blog.quux.de | jabber: jenslink@guug.de | ------------------- |
-------------------------------------------------------------------------
Re: Common operational misconceptions [ In reply to ]
On Feb 17, 2012, at 6:52 AM, -Hammer- wrote:

> Let me simplify that. If you are over 35 you know how to troubleshoot.
>

Is this a statement or something to be added to the list of misconceptions that are commonplace out there?

Not trying to be flip... Honestly asking the question. I can see it going either way, frankly. ;-)

Owen
RE: Common operational misconceptions [ In reply to ]
Exactly right. They have some much information floating around in their
heads many of them cannot fit it together. But once they get on the job, all
of those little synapses rapidly connect, and then the light comes on.

Higher education is just like drivers education. You did not learn to drive
in drivers education. You learned how to drive by driving. Higher education
gives you the foundation on which to learn.

-----Original Message-----
From: Paul Graydon [mailto:paul@paulgraydon.co.uk]
Sent: Friday, February 17, 2012 12:33 PM
To: nanog@nanog.org
Subject: Re: Common operational misconceptions

On 02/17/2012 04:29 AM, Leo Bicknell wrote:
> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul
Graydon wrote:
>> At the same time, it's shocking how many network people I come across
>> with no real grasp of even what OSI means by each layer, even if it's
>> only in theory. Just having a grasp of that makes all the world of
>> difference when it comes to troubleshooting. Start at layer 1 and
>> work upwards (unless you're able to make appropriate intuitive
>> leaps.) Is it physically connected? Are the link lights flashing? Can
>> traffic route to it, etc. etc.
> I wouldn't call it a "misconception", but I want to echo Paul's
> comment. I would venture over 90% of the engineers I work with have
> no idea how to troubleshoot properly. Thinking back to my own
> education, I don't recall anyone in highschool or college attempting
> to teach troubleshooting skills. Most classes teach you how to build
> things, not deal with them when they are broken.
The Cisco CCNA syllabus used to emphasise the layer 1->7 approach to
troubleshooting. Not sure if they still do, or if trainers even bother to
mention it (mine did back when I did it several years ago)

> The basic skills are probably obvious to someone who might design
> course material if they sat down and thought about how to teach
> troubleshooting. However, there is one area that may not be obvious.
> There's also a group management problem. Many times troubleshooting
> is done with multiple folks on the phone (say, customer, ISP and
> vendor). Not only do you have to know how to troubleshoot, but how to
> get everyone on the same page so every possible cause isn't tested 3
> times.
Never trust what you can't prove yourself, that includes vendors and
customers. Every now and then I forget this and find hours later that I've
wasted a whole bunch of time because I trusted when someone said something
that it actually was the case. It's really often better to test something a
third time even if Vendor and Customer tell you something is a particular
way.

>
> I think all college level courses should include a "break/fix"
> exercise/module after learning how to build something, and much of
> that should be done in a group enviornment.
>
Definitely. I've learnt more in my time from breaking things than I've ever
learnt setting them up; however the education system is focused on breadth
of knowledge, not depth. Students are expected to be able to regurgitate
ridiculous amounts of facts and figures, so that they pass standardised
tests, not understand how to actually use them.

Paul
Re: Common operational misconceptions [ In reply to ]
On Feb 17, 2012, at 7:20 AM, David Barak wrote:

>> From: Owen DeLong owen@delong.com
>
>> Sigh... NAT is a horrible hack that served us all too well in address conservation. Beyond that, it is merely a source of pain.
>
> I understand why you say that - NAT did yeoman's work in address conservation. However, it also enabled (yes, really) lots of topologies and approaches which are *not* designed upon the end-to-end model. Some of these approaches have found their way into business proceses.
>
Yes... An unfortunate and very damaging side effect to be sure.

> An argument you and others have made many times boils down to "but if we never had NAT, think how much better it would be!"
>
> To this, the response "so what?" is not unreasonable - organizations which have built up processes and products around the non-end-to-end model may or may not see a benefit in changing their ways. Asserting that there is something wrong with existing, succesful business practices is not, by itself, compelling.
>

People who make money selling weapons don't necessarily see a benefit to peace. People who avoid the high costs of toxic waste disposal by putting it into ground water don't necessarily see a benefit to having an EPA or laws that prohibit doing so.

If you're not party to the war and you're not one of the people whose water supply is affected by the toxins flowing into it, then, the response "so what?" may seem reasonable from your perspective.

NAT is much the same way. It is a form of toxic pollutant that has damaging effects outside of the business that has chosen to deploy NAT. At best, it started out as a necessary evil for address conservation. Dependence on it beyond that seems to me to be akin to a form of drug addiction.

> While you and I may find this type of packet header manipulation distasteful, there's lots of organizations for which it's normal operations. The more NAT for v6 gets fought, the more folks will fight to preserve it. Time could be better spent demonstrating why NAT isn't needed in X or Y use case, and providing configuration snippets / assistance for non-NAT-based solutions to those various groups.
>

And I do exactly that when presented with actual use cases where people believe NAT is needed.

You can find several instances of my having done that in previous NANOG threads.

Owen
Re: Common operational misconceptions [ In reply to ]
Now, come on... If you're in the 40-50 range, you should have put octal before hex. :p

Owen
(Who grew up on a PDP-11 in his high-school and still remembers 1777300 and its significance to anyone who has used a larger PDP system)

On Feb 17, 2012, at 7:51 AM, -Hammer- wrote:

> Mario,
> I was kinda having fun and kinda not. My point is that the 40-50 year olds that were doing this 30 years ago grew up understanding things in order. Bits. Bytes. KiloBits. KiloBytes. (Some folks still get those confused). Hex. etc. Move on to the OSI model and it's the same thing. Voltage. Amplitude. Binary. etc. I think that this generation that I'm referring to is a great generation because we were at the beginning of the Internet blooming. There are folks on this forum that go back further. Into DARPA. Before DARPA was just chapter 1 one every single Cisco Press book. They have a unique understanding of the layers. I had that understanding in my 20s. The technology is so complicated these days that many folks miss those fundamentals and go right into VSS on the 6500s or MPLS over Juniper. In the end, it all comes in time.
>
> -Hammer-
>
> "I was a normal American nerd"
> -Jack Herer
>
>
>
> On 2/17/2012 9:12 AM, Mario Eirea wrote:
>> Well, I will argue this. I think the important factor in any troubleshooting is having a real understanding of how the system works. That is, how different things interact with each others to achieve a specific goal. The biggest problem I see is that many people understand understand the individual parts but when it comes to understanding the system as a whole they fall miserably short.
>>
>> A short example, probably not the best but the one that comes to mind right now:
>>
>> Someone replaces a device on the network with a new one. They give it the same IP address as the old device. They don't understand why the router cant communicate with it at first and then starts working. The people "understand" ARP, but cant correlate one event with another.
>>
>> I guess if your 35 you have seen this at least once and can fix it. But what happens if you have never seen this problem or a related one? At this point your going to have to really troubleshoot, not just go on experience.
>>
>> Mario Eirea
>> ________________________________________
>> From: -Hammer- [bhmccie@gmail.com]
>> Sent: Friday, February 17, 2012 9:52 AM
>> To: nanog@nanog.org
>> Subject: Re: Common operational misconceptions
>>
>> Let me simplify that. If you are over 35 you know how to troubleshoot.
>>
>> Yes, I'm going to get flamed. Yes, there are exceptions in both directions.
>>
>> -Hammer-
>>
>> "I was a normal American nerd"
>> -Jack Herer
>>
>>
>>
>> On 2/17/2012 8:29 AM, Leo Bicknell wrote:
>>> In a message written on Thu, Feb 16, 2012 at 08:50:11PM -1000, Paul Graydon wrote:
>>>> At the same time, it's shocking how many network people I come across
>>>> with no real grasp of even what OSI means by each layer, even if it's
>>>> only in theory. Just having a grasp of that makes all the world of
>>>> difference when it comes to troubleshooting. Start at layer 1 and work
>>>> upwards (unless you're able to make appropriate intuitive leaps.) Is it
>>>> physically connected? Are the link lights flashing? Can traffic route to
>>>> it, etc. etc.
>>> I wouldn't call it a "misconception", but I want to echo Paul's
>>> comment. I would venture over 90% of the engineers I work with
>>> have no idea how to troubleshoot properly. Thinking back to my own
>>> education, I don't recall anyone in highschool or college attempting
>>> to teach troubleshooting skills. Most classes teach you how to
>>> build things, not deal with them when they are broken.
>>>
>>> The basic skills are probably obvious to someone who might design
>>> course material if they sat down and thought about how to teach
>>> troubleshooting. However, there is one area that may not be obvious.
>>> There's also a group management problem. Many times troubleshooting
>>> is done with multiple folks on the phone (say, customer, ISP and
>>> vendor). Not only do you have to know how to troubleshoot, but how
>>> to get everyone on the same page so every possible cause isn't
>>> tested 3 times.
>>>
>>> I think all college level courses should include a "break/fix"
>>> exercise/module after learning how to build something, and much of that
>>> should be done in a group enviornment.
>>>
>>
Re: Common operational misconceptions [ In reply to ]
This reminds me of what I think is the biggest root misconception of the 20th and 21st centuries:

Rapid step-by-step training can replace conceptual education on the fundamentals.

In other words, we have moved from the old-school of teaching people why things work and how they work to a newer school of teaching people how to complete specific tasks. This has had the following negative effects, IMHO:

1. When the only tool you have is a hammer, you try to mold every problem into a nail.
2. When you only know a procedure for doing something and don't understand the fundamentals
of why X is supposed to occur at step Y, then when you get result A instead of X, your only options
are to either continue to step Z and hope everything turns out OK, or, go back to an earlier step
and hope everything works this time.
3. Troubleshooting skills are limited to knowing the number of the vendor's help desk.

I once worked with a director of QA that epitomized this. It was a small company, so, as director, he was directly responsible for most of the tasks in the QA lab. He was meticulous in following directions which was a good thing. However, when he reached a step where he did not get the expected result, he was limited to telling the engineers that the test failed at step X and would not make any effort to identify or resolve the problem and would literally block the entire QA process waiting for engineering to resolve the issue before he would continue testing. Worse, he would not test independent pieces of the system in parallel, so, when he blocked on one system failing, he wouldn't test the others, either. Further investigation revealed that this was because he didn't actually know which systems were or were not dependent on each other. He was so completely immersed in the procedural school of thought that he was literally unwilling to accept conceptual knowledge or develop an understanding of the theory and principles of operation of any of the systems.

Owen

On Feb 17, 2012, at 8:13 AM, Mario Eirea wrote:

> I definitely understand and agree with what you saying. Actually, most my friends are over 50 years old... I do agree with you on the generational statement. My argument was that many people over 35 have no idea what they are doing, and some under 35 do know what they are doing. On thing is for sure, experience goes a long way. The importance is knowing the fundamentals and putting it all together (a skill that has been lost in recent times)
>
> I have a lot to say about the current generation of people growing up in this country, but that's a whole other thread in a whole other list. :-)
>
> Mario Eirea
>

1 2 3 4 5 6 7 8 9  View All