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- [bhmc...@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. >>> >>
