Re: Common operational misconceptions

[-Hammer- <bhmccie () gmail com>]

I give I give. I should have. But I left a bunch of stuff out and the 
folks that I'm referring to know it. One of the fun things I do with 
network guys is ask them about canonical bit ordering across routers. 
Always causes the room to go quiet. Them someone of the appropriate age 
group will speak up after he's done laughing.

The best thing I have ever figured out to tell less experienced (I 
didn't say younger) folks is to start at the bottom of the stack and 
work your way up. That's the way many of us troubleshoot. Is the cable 
on the floor? That's bad. If not, is the ARP entry incomplete? That's 
bad. If not, is the route missing? That's bad. If not, can you reach the 
route? Try this radical command that was invented by Steve Jobs while 
working on his first IPhone (They won't know who Vint Cerf or anyone 
else is and by using Steves name they will trust you)(I run Android):
telnet 1.2.3.4 1433
What? It answered? So the SQL service is running? Then it ain't the 
network dude....
So many times people don't pick up on that. But when they do, it's like 
a light bulb went off and they see the world differently. Like 
subnetting....

-Hammer-

"I was a normal American nerd"
-Jack Herer



On 2/17/2012 12:49 PM, Owen DeLong wrote:
> 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.