Re: Which P-Touch should I have?
Subject: Re: Which P-Touch should I have? Date: Thu, Feb 16, 2012 at 07:45:29PM -0500 Quoting William Herrin (b...@herrin.us): For cable labeling I've had good results with 3M Scotch Super88 color electrical tape. Pick unique color bands for each cable. Band it identically at both ends. You don't have to squint to see how it's labeled. And the label isn't invalidated merely because you unplugged it from one place and plugged it in somewhere else. At previous employer, we ordered two identical rolls of Brady (IIRC) numbered labels. Every cable got numbered in both ends and the number, being unique at the site, could be used for documentation as well as finding both ends in looms etc. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 LBJ, LBJ, how many JOKES did you tell today??! signature.asc Description: Digital signature
Re: common time-management mistake: rack stack
I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// brandon
RE: common time-management mistake: rack stack
With apologies to Randy, let the CCNAs fight with label makers. No, your CTO shouldn't be racking and stacking routers all the time. The fundamental concept of an organizational hierarchy dictates that. But a CTO who has lost touch with the challenges inherent in racking and stacking a router can't effectively support his team. See the TV series 'undercover boss' for a (possibly trite and clichéd) example of this. Your position never gives you the right to command. It only imposes on you the duty of so living your life that others can receive your orders without being humiliated. --Dag Hammarskjold
Re: Anonymous planning a root-servers party
On Wed, Feb 15, 2012 at 10:36:32PM +, George Bakos gba...@alpinista.org wrote a message of 13 lines which said: As I hadn't seen it discussed here, I'll have to assume that many NANOGers haven't seen the latest rant from Anonymous: There's nothing proving that it comes from the Anonymous (the name is itself quite fuzzy, anyone can say I am the Anonymous). It may be a student playing, it may be a security vendor trying to raise more security awareness, etc. A post on pastebin means nothing.
Re: Anonymous planning a root-servers party
On Wed, Feb 15, 2012 at 04:40:47PM -0600, Grant Ridder shortdudey...@gmail.com wrote a message of 23 lines which said: If i remember right, another group tried to take down the root servers within the past 5 or 6 years and only took out around 20 or 25. No need to remember, Wikipedia does it for you http://en.wikipedia.org/wiki/Distributed_denial_of_service_attacks_on_root_nameservers.
Re: common time-management mistake: rack stack
+1 I picked up ram from a supplier today. Could have used a courier, but getting out of the office is vital. A CTO who's lost touch because they haven't been to a remote site in half a decade is a business risk, more so than the CTO being away from their desk. If there is business risk from having the CTO out of touch for a week or even a month then there's a bigger problem. D On 17/02/2012 9:17 p.m., Brandon Butterworth wrote: I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// brandon -- Don Gould 31 Acheson Ave Mairehau Christchurch, New Zealand Ph: + 64 3 348 7235 Mobile: + 64 21 114 0699
Re: Which P-Touch should I have?
Subject: RE: Which P-Touch should I have? Date: Thu, Feb 16, 2012 at 11:20:37PM -0600 Quoting Kenneth M. Chipps Ph.D. (chi...@chipps.com): I don't suppose anyone follows the TIA-606-B Administration Standard for the Telecommunications Infrastructure of Commercial Buildings when labeling things like cables. The swedish equivalents are way to tree-centric, meaning it is hard to assign codes to stuff like fiber path between rooms that do not pass the One Interconnect In The Basement. We did a 600x600mm grid in the entire building (fitting the footprint of an ETSI frame, or two 300mm deep cabinets as well as being one european floor tile.) and then every cable documentation refered grid number and HE. (German for RU) So a cable could be referenced with AA92:12 - AB36:14, but the only label on the cable was a serial number. -- Måns Nilsson primary/secondary/besserwisser/machina MN-1334-RIPE +46 705 989668 YOU!! Give me the CUTEST, PINKEST, most charming little VICTORIAN DOLLHOUSE you can find!! An make it SNAPPY!! signature.asc Description: Digital signature
Re: common time-management mistake: rack stack
On Feb 17, 2012, at 3:17 AM, Brandon Butterworth wrote: I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. +1 I find this myself, it's useful to do this, as it is to sit in with the operations team and other groups (even finance) to understand what other groups need/require. I've often found that someone is working around a problem they didn't know you could solve (easily), or is doing a large amount of manual labor when there is an API, etc. Perspective is good. I also do other work that certainly isn't a complete use of my talents that benefits others (e.g.: chaperone a field-trip at school). These are not without merits, but I do know I have my faults in perhaps reading (and responding) to NANOG too much when I should be engaged in more worthwhile tasks. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// - Jared
RE: common time-management mistake: rack stack
I think it was Miagi in Karate Kid that stressed balance. The CTO who is NEVER out of his cage is dangerous, likewise the one that is never available is also. It is keeping in touch with what is happening at all levels that makes him valuable. If there is one thing that American Management misses, it is that. The GROWING companies almost always have management that is active, visible and accessible - top to bottom. The ones that are dying are not. The same goes for union leaders who are really pseudo-management. The senior technicians are no different than management, they need broad focus but they must also be able to take the magnifying glass and look at the current situation. A network engineer who cannot do both is not living up to his job description. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: Jared Mauch [mailto:ja...@puck.nether.net] Sent: Friday, February 17, 2012 8:36 AM To: Brandon Butterworth Cc: nanog@nanog.org Subject: Re: common time-management mistake: rack stack On Feb 17, 2012, at 3:17 AM, Brandon Butterworth wrote: I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. +1 I find this myself, it's useful to do this, as it is to sit in with the operations team and other groups (even finance) to understand what other groups need/require. I've often found that someone is working around a problem they didn't know you could solve (easily), or is doing a large amount of manual labor when there is an API, etc. Perspective is good. I also do other work that certainly isn't a complete use of my talents that benefits others (e.g.: chaperone a field-trip at school). These are not without merits, but I do know I have my faults in perhaps reading (and responding) to NANOG too much when I should be engaged in more worthwhile tasks. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// - Jared
Spam from Telx
So, anyone else get spammed by Telx after posting to nanog? This is massively unprofessional. Nick Original Message Subject: RE: telx Date: Fri, 17 Feb 2012 13:47:25 + From: George Fitzpatrick gfitzpatr...@telx.com To: Hi , We have some exciting things happening here at Telx that can help your network connectivity. Can we chat for 5 minutes? Thanks, George 917.371.7257
Re: common time-management mistake: rack stack
I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet. As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time. on the contrary, we'd PREFER if CEO's and CTO's of our trading partners know what their company is doing and how their core network actually works. (Rather than just giving one of those stupid flyers with a world map and some lines representing their network to potential customers ;) no startrek questions pls. :P. (and rack stack with routers is something else than rack stack with serverfarms, as for servers, you can just as well have an installation company or the vendor do it for you (clearance issues set aside ;).. with routers its a bit more touchy which wire goes where exactly, and furthermore, they have to be individually configured during install, so its better to just be there, CTO or not CTO :P you might be confusing the CTO for the sales manager :P
RE: Spam from Telx
He has spammed by responding to posts that people have made in the past, he is still trolling I guess. James -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Friday, February 17, 2012 9:01 AM To: nanog@nanog.org Subject: Spam from Telx So, anyone else get spammed by Telx after posting to nanog? This is massively unprofessional. Nick Original Message Subject: RE: telx Date: Fri, 17 Feb 2012 13:47:25 + From: George Fitzpatrick gfitzpatr...@telx.com To: Hi , We have some exciting things happening here at Telx that can help your network connectivity. Can we chat for 5 minutes? Thanks, George 917.371.7257
Re: Anonymous planning a root-servers party
the zionist usa regime does a far better job at taking icann out of the loop as a resolvable root than anonymous will ever able to do :P (time to change the root.hints to a competing root ;) the internet treats censorship as damage and routes around it, remember that one :P so can special agent retard of ICE put all those domains back nao pls :P you know the ones that say seized (must be american english for we don't care about the souvereignity of other countries and confiscate assets of their citizens nontheless ;) -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 17 Feb 2012, Stephane Bortzmeyer wrote: On Wed, Feb 15, 2012 at 04:40:47PM -0600, Grant Ridder shortdudey...@gmail.com wrote a message of 23 lines which said: If i remember right, another group tried to take down the root servers within the past 5 or 6 years and only took out around 20 or 25. No need to remember, Wikipedia does it for you http://en.wikipedia.org/wiki/Distributed_denial_of_service_attacks_on_root_nameservers.
Re: common time-management mistake: rack stack
Hi, Or sometimes you don't let a hazardous task like handling a Carrier Class Router to your CCNA in case they injure themself. Or worst... drop it =D ( From an actual experience ) - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 02/17/12 02:29, Jeff Wheeler wrote: Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't. I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet. As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time. With apologies to Randy, let the CCNAs fight with label makers.
Re: common time-management mistake: rack stack
On Fri, 17 Feb 2012, Brandon Butterworth wrote: It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. Definite +1 here. I got my start in this profession 15-ish years ago at a mid-sized regional ISP. The company was small enough, in terms of its work force, that that I interviewed with the CEO for what was largely an IT position. As a result, many people in the organization wore lots of different hats. It wasn't to the point of having accountants pull cable or IT guys doing the books, but I did spend a lot of time doing rack-and-stack work. I didn't (and still don't) mind rack-and-stack, pulling cable, etc. As others have said, it's a good, therapeutic diversion from staring at a screen and attending meetings ;) Another good reason for getting out into the field. When you're the person who defines technical deployment standards for an organization, it gives you an opportunity to verify that work is being done to those standards. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// I'm sure if the ISP I got my start with 15-ish years ago was much bigger, I would not have interviewed with the CEO, but at that time, it was the right fit for that organization. jms
Re: common time-management mistake: rack stack
Hrm. On Fri, Feb 17, 2012 at 3:17 AM, Brandon Butterworth bran...@rd.bbc.co.uk wrote: It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. This. One of the reasons I love my job so much is that I don't need to be stuck at a keyboard all the time. I usually volunteer to help rack and stack new hardware that I haven't had a chance to touch yet. For humans, touch can connect you to an object in a very personal way, make it seem more real. : ) -- Ray Soucy Epic Communications Specialist Phone: +1 (207) 561-3526 Networkmaine, a Unit of the University of Maine System http://www.networkmaine.net/
Re: Spam from Telx
On Fri, 17 Feb 2012, Nick Hilliard wrote: So, anyone else get spammed by Telx after posting to nanog? This is massively unprofessional. Yep - just got one a few minutes ago. I was just getting ready to spin up my trolling-for-business-by-scraping-addresses-from-nanog-is-bad-mojo response. jms We have some exciting things happening here at Telx that can help your network connectivity. Can we chat for 5 minutes? Thanks, George 917.371.7257
Re: common time-management mistake: rack stack
actually most west european countries have laws against having your employees lift up stuff heavier than 20 kilos :P you generally don't have insurance on your network-dude to handle such things *grin* if it drops on his foot, you're screwed. (or worse, on his hand ;) looking at the latest models we found units weighing 110 kilos *grin* i'm not lifting -that- up. -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 17 Feb 2012, Alain Hebert wrote: Hi, Or sometimes you don't let a hazardous task like handling a Carrier Class Router to your CCNA in case they injure themself. Or worst... drop it =D ( From an actual experience ) - Alain Hebertaheb...@pubnix.net PubNIX Inc. 50 boul. St-Charles P.O. Box 26770 Beaconsfield, Quebec H9W 6G7 Tel: 514-990-5911 http://www.pubnix.netFax: 514-990-9443 On 02/17/12 02:29, Jeff Wheeler wrote: Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't. I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet. As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time. With apologies to Randy, let the CCNAs fight with label makers.
Re: Spam from Telx
\o/ i got one too, i'll put a bunch of sales droids on this George from telx right away to make him an offer in return *grin* (this is how you treat ppl trying to sell you something in an aggressive manner, you just have your people try to sell -them- something in return ;) On Fri, 17 Feb 2012, Justin M. Streiner wrote: On Fri, 17 Feb 2012, Nick Hilliard wrote: So, anyone else get spammed by Telx after posting to nanog? This is massively unprofessional. Yep - just got one a few minutes ago. I was just getting ready to spin up my trolling-for-business-by-scraping-addresses-from-nanog-is-bad-mojo response. jms We have some exciting things happening here at Telx that can help your network connectivity. Can we chat for 5 minutes? Thanks, George 917.371.7257
Re: Spam from Telx
Ya, i got a message 2 days ago from them. It was very vague. Only 2 sentences. -Grant On Fri, Feb 17, 2012 at 8:15 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Fri, 17 Feb 2012, Nick Hilliard wrote: So, anyone else get spammed by Telx after posting to nanog? This is massively unprofessional. Yep - just got one a few minutes ago. I was just getting ready to spin up my trolling-for-business-by-**scraping-addresses-from-nanog-**is-bad-mojo response. jms We have some exciting things happening here at Telx that can help your network connectivity. Can we chat for 5 minutes? Thanks, George 917.371.7257
Re: Common operational misconceptions
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. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpqM2WcB0gd1.pgp Description: PGP signature
Re: Common operational misconceptions
This list is awesome. Is anyone consolidating it? I'm still catching up on the thread -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 1:05 AM, Carsten Bormann wrote: On Feb 17, 2012, at 07:50, Paul Graydon wrote: what OSI means Yet another common misconception popping up: -- You can talk about the OSI model in the present tense (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions. It is also still useful as a way to calibrate your gut feeling of what is going on in a network. Just never expect OSI terms to have a precise meaning in today's networks. 1978 is now a third of a century ago... If you need precision, you need to spell out what you mean in today's terms.) Grüße, Carsten
Re: common time-management mistake: rack stack
On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote: actually most west european countries have laws against having your employees lift up stuff heavier than 20 kilos :P IT job postings in the US often include physical qualifiers such as must be able to lift weights of up to 50 pounds (~22.7 kilos) and must be able to use hand tools. The lecture about using safe lifting practices usually waits until after you accept the job and go through your new-employee orientation :) jms
Re: common time-management mistake: rack stack
In a message written on Fri, Feb 17, 2012 at 02:29:36AM -0500, Jeff Wheeler wrote: Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. At the risk of offending many folks on NANOG, our industry is more like a trade than a profession. In many cases we would do better to treat our people (in terms of how they are managed) like skilled trades, electricians, plumbers, metal fitters, rather than pretend they are white collar professionals. Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control. To your point, if you look at skilled trades the simpler the task the more likely it will fall to the new guy. Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc. But key to an apprenticeship is that the senior guy does some of the low level work some of the time, and _shows_ the junior guy how to do it right. The senior guy might rack or stack a couple of boxes each colo they visit, and relate concepts like how the screw hole spacing works in the rack rails, how to plan cable management, proper labeling, and so on. It really accomplishes much of what everyone else is talking about, while still being productive. The old hat gets the downtime and catharsis of doing a simple, yet productive task. The new guy gets to learn how to do the job properly. The employer knows the work has been done right, as it was overseen by the old hat, and that they will have someone to replace him when the old hat retires. Maybe if we did more apprecenship style learning folks would still know how to wrap cables with wax string. It's simple, fast, and works well. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpAFTnus5s74.pgp Description: PGP signature
RE: Common operational misconceptions
Actually I taught in a three year tech program for a while and although trouble shooting was not in the curriculum, and as far as I know it isn't anywhere, several of us adjunct faculty did teach it and got reprimanded for it as part of our classes. So much for the education industry understanding the needs of business. I taught basic PC hardware and NT networking at the time. We would actually have the students assemble a PC and then in a subsequent class bring up a network. I got pretty good at nailing then with bugs while they were on breaks. Heck, they had to go out to smoke. They would come back with a network or PC that was no longer working. I would then have them explain what they saw, what they thought was wrong, justify it BEFORE they could take any corrective action. I also used some classroom scenarios - they could ask me anything that they could physically learn if they could tell me how they would check that. I let them run bad rabbit trails if it looked like it would cement the right way. It taught some step by step processes. BTW, the best trouble shooting course I have ever taken was the Kepner Trego Problem Analysis/Decision Analysis class. Caterpillar used it but I have not seen it run anywhere in years. It is hard-nosed and may not be glitzy enough for today. If you have a junior tech who isn't getting there, I suggest - get their book and see if it helps. NO, I do not sell them or have stock in the company and NO, it will not do any good unless he reads it. I still use methodologies I learned in the class. Ralph Brandt Communications Engineer HP Enterprise Services Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Friday, February 17, 2012 9:29 AM To: nanog@nanog.org Subject: Re: Common operational misconceptions 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. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
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: Spam from Telx
On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote: \o/ i got one too, i'll put a bunch of sales droids on this George from telx right away to make him an offer in return *grin* I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days jms
Re: Spam from Telx
I didn't even respond. I think many of these high-pressure-aggressive-types always have an answer like that conveniently vague enough as to give them an out. On Fri, Feb 17, 2012 at 9:54 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote: \o/ i got one too, i'll put a bunch of sales droids on this George from telx right away to make him an offer in return *grin* I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days jms
RE: Common operational misconceptions
+1 Mario Eirea From: Leo Bicknell [bickn...@ufp.org] Sent: Friday, February 17, 2012 9:29 AM To: nanog@nanog.org Subject: Re: Common operational misconceptions 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. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
RE: Common operational misconceptions
Hammer, you are at least 75% right. You will get flamed and in most cases, the 35 year age is close to right. But then in Programming where I spent most of my IT time since Feb 1963, few current programmers have skills that they need to be really successful. Same thing. It is the fault of the educational system like one school district here that teaches Alice, VB and then two days of C++ to High School Kids. Heck, they will fiddle with Alice on their own. They need some exposure to one of the SQL's and how to build some tables, maybe a good script language, some command line on SQL+ and unix or PostgresSQL and linux if the school can't afford the unix licenses. The fun and games is more important than the substance and it goes into the colleges in spades. 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 Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: -Hammer- [mailto: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.
Re: Spam from Telx
On Fri, 17 Feb 2012, Charles Mills wrote: I didn't even respond. I think many of these high-pressure-aggressive-types always have an answer like that conveniently vague enough as to give them an out. I did mention to him that such tactics were likely to create a large group of people who will never do business with Telx. It's equivalent to having someone call you out of the blue to sell you a car, whether you're in the market to buy or not. jms
Re: Spam from Telx
In other words he bought a list of leads. On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Spam from Telx
On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote: In other words he bought a list of leads. Possibly, albeit a poorly screened list of leads. jms On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Spam from Telx
needless to say their own website is slow as poo through a coffee filter :P reminds me of the isdn days :P -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote: In other words he bought a list of leads. On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days -- Suresh Ramasubramanian (ops.li...@gmail.com)
Re: Spam from Telx
we have something exitig happening at telx! we are now connected to the backbone through a 128kbit/s adsl line! -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote: needless to say their own website is slow as poo through a coffee filter :P reminds me of the isdn days :P -- Greetings, Sven Olaf Kamphuis, CB3ROB Ltd. Co. KG = Address: Koloniestrasse 34 VAT Tax ID: DE267268209 D-13359 Registration:HRA 42834 B BERLINPhone: +31/(0)87-8747479 Germany GSM: +49/(0)152-26410799 RIPE:CBSK1-RIPEe-Mail: s...@cb3rob.net = penpen C3P0, der elektrische Westerwelle http://www.facebook.com/cb3rob = Confidential: Please be advised that the information contained in this email message, including all attached documents or files, is privileged and confidential and is intended only for the use of the individual or individuals addressed. Any other use, dissemination, distribution or copying of this communication is strictly prohibited. On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote: In other words he bought a list of leads. On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. ??It's going to be one of those days -- Suresh Ramasubramanian (ops.li...@gmail.com)
RE: Common operational misconceptions
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.
Re: Common operational misconceptions
On 2/17/2012 1:05 AM, Carsten Bormann wrote: On Feb 17, 2012, at 07:50, Paul Graydon wrote: what OSI means Yet another common misconception popping up: -- You can talk about the OSI model in the present tense (That said -- yes, it is still useful as a set of simple terms for certain combinations of functions. It is also still useful as a way to calibrate your gut feeling of what is going on in a network. Just never expect OSI terms to have a precise meaning in today's networks. 1978 is now a third of a century ago... If you need precision, you need to spell out what you mean in today's terms.) Actually, I find it makes a perfect troubleshooting guideline in today's world; at least up to layer 4. I'm not saying it's a perfect match to troubleshooting a variety of MPLS problems, but it is a reminder that there are dependencies which must be checked. In dealing with transport companies, the model is still a good representation of their service levels. It isn't uncommon to find their products defined as layer 2 services (ranging from tdm/sonet services to ethernet switching services), layer 3 services (often handled by their ISP department), and MPLS services (which can range from p2p transport to l3vpn). Which brings up my final point. Until we quit naming things l2vpn or l3vpn, OSI still applies. :P Jack
Re: Spam from Telx
No he didnt. The one he sent to me actually included part of the thread he picked me up from. I told him the most exciting thing he could do is to not spam me again. Poor guy, did nobody tell him? -- Leigh Porter On 17 Feb 2012, at 15:11, Justin M. Streiner strei...@cluebyfour.org wrote: On Fri, 17 Feb 2012, Suresh Ramasubramanian wrote: In other words he bought a list of leads. Possibly, albeit a poorly screened list of leads. jms On Fri, Feb 17, 2012 at 8:24 PM, Justin M. Streiner strei...@cluebyfour.org wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days -- Suresh Ramasubramanian (ops.li...@gmail.com) __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __ __ This email has been scanned by the Symantec Email Security.cloud service. For more information please visit http://www.symanteccloud.com __
Re: Common operational misconceptions
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. On 02/17/2012 10: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. -- Stephen Clark *NetWolves* Director of Technology Phone: 813-579-3200 Fax: 813-882-0209 Email: steve.cl...@netwolves.com http://www.netwolves.com
Re: Spam from Telx
On Sat, 18 Feb 2012, Mark Andrews wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days It's a little hard to says that with a straight face when it has a copy of the message posted to nanog attached. It's even more amusing when your company is already listed in the pdf. The message I got was a bit more sanitized. Guess I was lucky ;) jms
Which way to fold the label (was: Re: time sink 42)
- Original Message - From: Karl Auer ka...@biplane.com.au On Thu, 2012-02-16 at 17:17 -0500, Jay Ashworth wrote: Fold one of the corners of the label, just a tiny corner, back towards the backing paper, then forward. It matters which way you bend, because of the relative stiffness of the paper and the plastic; you have to bend *towards* the paper, which will stay folded, away from the plastic. What?!? Forward instead of backward? KILL THE UNBELIEVER! KILL! KILL! Way to misquote me, Karl. :-) The alternative approach, to which ALL right-thinking persons subscribe, is to avoid, as much as possible, folding the label. Because, indeed and as you say, it will remain folded. If the label does have to be bent, it should be left bent down, not up. Bending it towards the backing may work on it's own, subjecting the backing paper to the more acute deformation, and the label may even thereafter return to the flat position uncreased, leaving the backing paper separated. The more destructive bend upwards may also leave a corner of the label bent up and away from the surface the label will be on. It isn't necessary to bend it so sharply that the crease will stay in the plastic, no. And no, I didn't say the label would stay folded. I said the backing would stay folded. GET IT RIGHT!ONEELEVENTYONE! The Covenant of the Holy Order of Downfolders meets weekly behind the fourth server rack from the left, lower basement. Batteries not supplied. Bring your own torch, pitchfork, etc. Magic? Or More Magic? Cheers, -- jr 'here commenceth the whacky weekend' a -- Jay R. Ashworth Baylink j...@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: Hi speed trading - hi speed monitoring
- Original Message - From: Paul Graydon p...@paulgraydon.co.uk Anecdotally, I had an interview years ago for a small-ish futures trading company based in London. The interviewer had to pause the interview part way through whilst he investigated a 10ms latency spike that the traders were noticing on a short point-to-point fiber link to the London Stock Exchange. He commented that the traders were far better at 'feeling' when an connection was showing even a trace of lag compared to normal than anything he'd set up by way of monitoring (not sure how good his monitoring was, though.) This was my experience in a callcenter as well; network type problem reports always came in from the floor managers before Nagios came forth with an opinion. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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
- Original Message - From: Ridwan Sami rms2...@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. Cheers, -- jr 'among dozens of other legitimate uses' a -- Jay R. Ashworth Baylink j...@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
On Feb 17, 2012, at 9:29 AM, -Hammer- wrote: This list is awesome. Is anyone consolidating it? I'm still catching up on the thread I was thinking of making a checklist out of it. - Jared
Re: Spam from Telx
I've been getting voicemails from someone, leaving a first name only saying they have question that only I can answer. Dangling bait like that is a big red flag so they don't get a callback. On Fri, Feb 17, 2012 at 10:28 AM, Justin M. Streiner strei...@cluebyfour.org wrote: On Sat, 18 Feb 2012, Mark Andrews wrote: I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days It's a little hard to says that with a straight face when it has a copy of the message posted to nanog attached. It's even more amusing when your company is already listed in the pdf. The message I got was a bit more sanitized. Guess I was lucky ;) jms
One solution -- time sink 42
Here's a little trick that works really well for those types of labels. Have you watched professional wrappers at Christmas time curling ribbon with a pair of scissors? It works for removing the backing from the labels as well. Hold the backing of the label against the side of a pair of scissors / knife / even a key with some sharper points on it, and drag it across the edge. This will make the ends separate a little bit, allowing you to take hold and easily separate the pieces. Check out this site that shows it being done with scissors if you've never seen it http://www.wikihow.com/Curl-Ribbon Make sure it's the backing side being scraped across the scissors, not the printed side. Wade -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Thursday, February 16, 2012 4:09 PM To: North American Network Operators' Group Subject: time sink 42 ok, this is horribly pragmatic, but it's real. yesterday i was in the westin playing rack and stack for five hours. an horrifyingly large amount of my time was spent trying to peel apart labels made on my portable brother label tape maker, yes peeling the backing from a little label so remote hands could easily confirm a server they were going to attack. is there a trick? is there a (not expensive) different labeling machine or technique i should use? randy This electronic mail, including any attachments, is confidential and is for the sole use of the intended recipient and may be privileged. Any unauthorized distribution, copying, disclosure or review is prohibited. Neither communication over the Internet nor disclosure to anyone other than the intended recipient constitutes waiver of privilege. If you are not the intended recipient, please immediately notify the sender and then delete this communication and any attachments from your computer system and records without saving or forwarding it. Thank you.
Re: Common operational misconceptions
There is no legitimate reason for a user to use BitTorrent (someone will probably disagree with this). There is no democratic basis -for- copyright, so far for legitimate.
Re: Common operational misconceptions
Well said. An American tragedy. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:01 AM, Brandt, Ralph wrote: Hammer, you are at least 75% right. You will get flamed and in most cases, the 35 year age is close to right. But then in Programming where I spent most of my IT time since Feb 1963, few current programmers have skills that they need to be really successful. Same thing. It is the fault of the educational system like one school district here that teaches Alice, VB and then two days of C++ to High School Kids. Heck, they will fiddle with Alice on their own. They need some exposure to one of the SQL's and how to build some tables, maybe a good script language, some command line on SQL+ and unix or PostgresSQL and linux if the school can't afford the unix licenses. The fun and games is more important than the substance and it goes into the colleges in spades. 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 Telephone +1 717.506.0802 FAX +1 717.506.4358 Email ralph.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: -Hammer- [mailto: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.
Re: Common operational misconceptions
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. Jack
Re: Spam from Telx
Once upon a time, Justin M. Streiner strei...@cluebyfour.org said: On Fri, 17 Feb 2012, Sven Olaf Kamphuis wrote: \o/ i got one too, i'll put a bunch of sales droids on this George from telx right away to make him an offer in return *grin* I did respond directly to him, and got a somewhat indignant response back, stating that he had no idea what I was talking about and that my contact information had come from an opt in email broker. It's going to be one of those days My personalized message from George was directly in reply to my post in the time sink 42 thread. He's subscribed to the list and just going down the message list hitting reply. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: Common operational misconceptions
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.
Re: Common operational misconceptions
If you do, please share it. Thank you. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:36 AM, Jared Mauch wrote: On Feb 17, 2012, at 9:29 AM, -Hammer- wrote: This list is awesome. Is anyone consolidating it? I'm still catching up on the thread I was thinking of making a checklist out of it. - Jared
Re: Common operational misconceptions
Original poster who started thread said he would. On Fri, Feb 17, 2012 at 10:51 AM, -Hammer- bhmc...@gmail.com wrote: If you do, please share it. Thank you. -Hammer- I was a normal American nerd -Jack Herer On 2/17/2012 9:36 AM, Jared Mauch wrote: On Feb 17, 2012, at 9:29 AM, -Hammer- wrote: This list is awesome. Is anyone consolidating it? I'm still catching up on the thread I was thinking of making a checklist out of it. - Jared
Re: Common operational misconceptions
On Fri, 17 Feb 2012 08:29:42 -0600 -Hammer- bhmc...@gmail.com wrote: This list is awesome. Is anyone consolidating it? I'm still catching up on the thread I'm collecting all responses, many of which have been sent to me off list. I was waiting for the thread to eventually end before summarizing it. Thanks everyone. John
Re: Common operational misconceptions
On 2/17/2012 10:04 AM, John Kristoff wrote: I was waiting for the thread to eventually end Greatest misconception of all. Jack
RE: Common operational misconceptions
It depends on how you define work well. As the RFC says: indication of some significantly disruptive event in the network, such as a router failure or a routing change to a path with a smaller MTU. it can not react against PMTU changes very well. It is seemingly working well means there is not much PMTU changes, which means we had better assumes some PMTU (1280B, for example) and use it without PMTUD. Masataka Ohta It depends on the OS and the method being used. If you set the option to 2 on Linux, it will do MTU probing constantly and react to MTU changes. Also, the MTU for a given path only lives for 5 minutes anyway (by default) and is rediscovered with Linux. (value in /proc/sys/net/ipv4/route/mtu_expires) but other operating systems may behave in other ways. I agree that if one tries hard enough, they can ensure a broken path and there are always people who seem to devote a lot of energy to that end. There's nothing that can be done about them but there is much the OS can try to do to defeat them at their task.
RE: Common operational misconceptions
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 From: -Hammer- [bhmc...@gmail.com] Sent: Friday, February 17, 2012 10:51 AM To: Mario Eirea Cc: nanog@nanog.org Subject: Re: Common operational misconceptions 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.
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 time-management mistake: rack stack
-Original Message- From: Jeff Wheeler Sent: Thursday, February 16, 2012 11:30 PM To: NANOG Subject: common time-management mistake: rack stack Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't. I see this as a double-edged sword. You don't want your C staff out in the field actually installing gear as a general course of operations as that is a great waste of their time/talent unless the C role is more honorary than anything else. That said, you might want a senior technical person on site overseeing the installation, checking the configuration, interfacing with vendor staff, testing things, etc. And it is good to have this senior staff member present when things go sideways as is often the case with new installations and often these issues are physical and are best solved with someone senior on site who can make decisions on the spot or carry more weight with the provider to get things done quickly. This should be someone that was involved in discussions with the vendor's rep. during the planning phase. If you get too reliant on sending only the cage monkeys (a term I use with fondness) then what happens when problems turn up greatly depend on your corporate culture. Do they simply stop, report the problem and wait for direction? Is there anyone on site that has the trust of the organization to make decisions on the fly and cut through the organizational red tape? Can they authorize a configuration change to work around something unforeseen? Having someone senior enough on site to make these decisions and carries some weight with the vendor can greatly reduce the time it takes to get a data center up and running. Granted, he doesn't need to be there when the initial cables are being laid out but should be there once equipment starts being installed in racks and configured. Having that experience and authority on site at the time of installation can be quite valuable.
Re: Common operational misconceptions
On Fri, Feb 17, 2012 at 10:33:12AM -0500, Jay Ashworth wrote: - Original Message - From: Ridwan Sami rms2...@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
Sent from my iPhone On Feb 17, 2012, at 7:48, Jack Bates jba...@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. Jack If i had a dollar for everytime i've heard that from a telco, i'd be a rich man...
RE: One solution -- time sink 42
My crappy PT-80 has this little slot in the top built for doing just this..it works pseudo-magically! Jesse Krembs - Data Network Architecture Planning FairPoint Communications | 800 Hinesburg Rd, South Burlington, VT 05403 | jkre...@fairpoint.com www.FairPoint.com| 802.951.1519 office | 802.735.4886 cell -Original Message- From: Kierstead, Wade [mailto:w...@e-novations.ca] Sent: Friday, February 17, 2012 10:41 AM To: 'Randy Bush'; 'North American Network Operators' Group' Subject: One solution -- time sink 42 Here's a little trick that works really well for those types of labels. Have you watched professional wrappers at Christmas time curling ribbon with a pair of scissors? It works for removing the backing from the labels as well. Hold the backing of the label against the side of a pair of scissors / knife / even a key with some sharper points on it, and drag it across the edge. This will make the ends separate a little bit, allowing you to take hold and easily separate the pieces. Check out this site that shows it being done with scissors if you've never seen it http://www.wikihow.com/Curl-Ribbon Make sure it's the backing side being scraped across the scissors, not the printed side. Wade -Original Message- From: Randy Bush [mailto:ra...@psg.com] Sent: Thursday, February 16, 2012 4:09 PM To: North American Network Operators' Group Subject: time sink 42 ok, this is horribly pragmatic, but it's real. yesterday i was in the westin playing rack and stack for five hours. an horrifyingly large amount of my time was spent trying to peel apart labels made on my portable brother label tape maker, yes peeling the backing from a little label so remote hands could easily confirm a server they were going to attack. is there a trick? is there a (not expensive) different labeling machine or technique i should use? randy This electronic mail, including any attachments, is confidential and is for the sole use of the intended recipient and may be privileged. Any unauthorized distribution, copying, disclosure or review is prohibited. Neither communication over the Internet nor disclosure to anyone other than the intended recipient constitutes waiver of privilege. If you are not the intended recipient, please immediately notify the sender and then delete this communication and any attachments from your computer system and records without saving or forwarding it. Thank you. ___ This e-mail message and its attachments are for the sole use of the intended recipients. They may contain confidential information, legally privileged information or other information subject to legal restrictions. If you are not the intended recipient of this message, please do not read, copy, use or disclose this message or its attachments, notify the sender by replying to this message and delete or destroy all copies of this message and attachments in all media.
Re: Common operational misconceptions
On Fri, Feb 17, 2012 at 06:52, -Hammer- bhmc...@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
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 jba...@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 mi...@mikea.ath.cx Tired old sysadmin
Re: Common operational misconceptions
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- bhmc...@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- [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.
Re: common time-management mistake: rack stack
On 2/17/12 06:18 , Sven Olaf Kamphuis wrote: actually most west european countries have laws against having your employees lift up stuff heavier than 20 kilos :P you generally don't have insurance on your network-dude to handle such things *grin* if it drops on his foot, you're screwed. (or worse, on his hand ;) looking at the latest models we found units weighing 110 kilos *grin* i'm not lifting -that- up. http://www.serverlift.com/solutions/products/sl500x-server-lift/
RE: common time-management mistake: rack stack
-Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Friday, February 17, 2012 6:46 AM To: NANOG Subject: Re: common time-management mistake: rack stack Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control. +1 I believe that can not be stressed enough. There is also another aspect to it in that about 15% of the population of people are abstract thinkers and 85% are concrete thinkers. The abstract thinkers are the ones who can come up with a vision in their head of how something should work as a system and then set out and build it. Or when they are faced with a problem, can in their head envision the work around and then apply that vision on site to do things such as rewire a portion of the network in a methodical fashion with no/little downtime. Those people are relatively rare and working with your line staff gives one an opportunity to assess the various talent sets of the people in the organization. The abstract thinkers are the ones good at being able to design a network from scratch and the concrete thinkers are the ones who will be great maintaining that network and keeping everything documented and done according to policy. You need both and it just so happens that you need more of one sort in just about the same proportion that you find them in the general population. The key is to identify which people have which talents and place them where their natural abilities more closely mesh with their job requirements. If you can do that, you can have a very powerful team. If you place people into positions simply based on the number of years in the organization or because of holes punched in the cert ticket, you might end up with people in positions that they don't really like or aren't particularly good at doing. The first step in building such an organization, though, is working closely with your people and attempting to identify whose natural abilities like in which direction. Sometimes it is more about talent than training, more about nature than nurture. To your point, if you look at skilled trades the simpler the task the more likely it will fall to the new guy. Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc. But at the same time, if you have a guy who might not be so sharp at troubleshooting a very complex network but is sharp as a tack when it comes to documenting things and keeping paperwork organized, that is a vital skill in the overall effort, too. That person should be given responsibility for maintaining more of the documentation, organizing things so they are easy for other employees to find, etc. and their pay should still continue to increase as they gain wider scope across more of the organization over time. The point is that it often takes many different sorts of skills and attempting to match people's natural talents to the requirements of the organization benefits both parties provided the individual involved doesn't see their position as a dead end. A good person of the sort mentioned above can literally save hours of time for people doing other tasks such as troubleshooting a problem. There is a certain synergy involved and some organizations recognize that, and some don't. Some are better in an architectural role, some are naturally better in a sustaining role, others are better at an organizational support role and (darned) few are good at all of those tasks. Sometimes we don't have the luxury of such specialization of roles, but some organizations do, particularly if they are in a phase of reorganization and downsizing. One thing to look at might not only be how good is this person in their current role but also would this person absolutely kick butt in a different role. But key to an apprenticeship is that the senior guy does some of the low level work some of the time, and _shows_ the junior guy how to do it right. The senior guy might rack or stack a couple of boxes each colo they visit, and relate concepts like how the screw hole spacing works in the rack rails, how to plan cable management, proper labeling, and so on. Actually, just having the senior person assist with some tasks such as moving/installing heavy/unwieldy gear does more than just show them how to do it right, it is actually quite an important almost sort of bonding experience between employees. It says I'm not allergic to work and not above doing the same job you are doing when it needs to get done, we are all
Re: common time-management mistake: rack stack
would have been good to know to whom you were replying, not in To: or in pre-quote text. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. It's not a waste, it's therapeutic, breaks the monotony of a desk job, you get a bit of exercise. Doing something mindless can help clear your thoughts, engineering yoga. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. That'd be a good idea, it's too easy to become remote from reality. obviously you need the right balance - s/big// i configure routers, admin servers, and occasionally rack and stack in my own research racks [0]. aside from giving me a base in reality instead of all research papers and power point (a major benefit), it's like housework or doing the dishes, shut up and do your part. it's also damned useful to maintain layer zero skills. once upon a time, when i was playing at vp eng, a london routing hub was supposed to be turned up. the equipment sat in co-lo receiving for weeks, and no respose from the london techs (i am sure they had ccnas, whetever the hell that is). so i grabbed my toolkit and got on a plane and walked into redbus and started turning it all up. the local techs appeared pretty damed quickly and started doing their jobs. of course, a few weeks later they were told to get jobs elsewhere. maintain your skills, you may need them again some day. randy --- [0] - deep thanks to (in alpha order) cisco, equinix, google, juniper, nsf, and others for contributions.
Re: Common operational misconceptions
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 rms2...@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: Hi speed trading - hi speed monitoring
On Fri, Feb 17, 2012 at 10:30:33AM -0500, Jay Ashworth wrote: - Original Message - From: Paul Graydon p...@paulgraydon.co.uk Anecdotally, I had an interview years ago for a small-ish futures trading company based in London. The interviewer had to pause the interview part way through whilst he investigated a 10ms latency spike that the traders were noticing on a short point-to-point fiber link to the London Stock Exchange. He commented that the traders were far better at 'feeling' when an connection was showing even a trace of lag compared to normal than anything he'd set up by way of monitoring (not sure how good his monitoring was, though.) This was my experience in a callcenter as well; network type problem reports always came in from the floor managers before Nagios came forth with an opinion. When I used to run an ISP network, our NOC always talked about that porn guy who would call the *exact* *momment* the NNTP server had any type of stutter... I guess there's always a canary for the coal mine -- eh?
Re: common time-management mistake: rack stack
On Fri, Feb 17, 2012 at 11:15 AM, George Bonser gbon...@seven.com wrote: -Original Message- From: Leo Bicknell [mailto:bickn...@ufp.org] Sent: Friday, February 17, 2012 6:46 AM To: NANOG Subject: Re: common time-management mistake: rack stack Low level employees should be apprenticed by higher level employees. Many of our skills are learned on the job; just like other trades someone with only book knowledge is darn near useless. Not only do those above need to teach, but they need to supervise, and exercise standards and quality control. +1 I believe that can not be stressed enough. There is also another aspect to it in that about 15% of the population of people are abstract thinkers and 85% are concrete thinkers. The abstract thinkers are the ones who can come up with a vision in their head of how something should work as a system and then set out and build it. Or when they are faced with a problem, can in their head envision the work around and then apply that vision on site to do things such as rewire a portion of the network in a methodical fashion with no/little downtime. Those people are relatively rare and working with your line staff gives one an opportunity to assess the various talent sets of the people in the organization. The abstract thinkers are the ones good at being able to design a network from scratch and the concrete thinkers are the ones who will be great maintaining that network and keeping everything documented and done according to policy. You need both and it just so happens that you need more of one sort in just about the same proportion that you find them in the general population. The key is to identify which people have which talents and place them where their natural abilities more closely mesh with their job requirements. If you can do that, you can have a very powerful team. If you place people into positions simply based on the number of years in the organization or because of holes punched in the cert ticket, you might end up with people in positions that they don't really like or aren't particularly good at doing. The first step in building such an organization, though, is working closely with your people and attempting to identify whose natural abilities like in which direction. Sometimes it is more about talent than training, more about nature than nurture. To your point, if you look at skilled trades the simpler the task the more likely it will fall to the new guy. Rack and stack is probably one of simplest jobs in our industry. A two man team, one senior, one junior, showing up at a colo may see the junior guy doing the physical work, while the senior guy works out any issues with the colo provider brings up the interconnection to them, etc. But at the same time, if you have a guy who might not be so sharp at troubleshooting a very complex network but is sharp as a tack when it comes to documenting things and keeping paperwork organized, that is a vital skill in the overall effort, too. That person should be given responsibility for maintaining more of the documentation, organizing things so they are easy for other employees to find, etc. and their pay should still continue to increase as they gain wider scope across more of the organization over time. The point is that it often takes many different sorts of skills and attempting to match people's natural talents to the requirements of the organization benefits both parties provided the individual involved doesn't see their position as a dead end. A good person of the sort mentioned above can literally save hours of time for people doing other tasks such as troubleshooting a problem. There is a certain synergy involved and some organizations recognize that, and some don't. Some are better in an architectural role, some are naturally better in a sustaining role, others are better at an organizational support role and (darned) few are good at all of those tasks. Sometimes we don't have the luxury of such specialization of roles, but some organizations do, particularly if they are in a phase of reorganization and downsizing. One thing to look at might not only be how good is this person in their current role but also would this person absolutely kick butt in a different role. But key to an apprenticeship is that the senior guy does some of the low level work some of the time, and _shows_ the junior guy how to do it right. The senior guy might rack or stack a couple of boxes each colo they visit, and relate concepts like how the screw hole spacing works in the rack rails, how to plan cable management, proper labeling, and so on. Actually, just having the senior person assist with some tasks such as moving/installing heavy/unwieldy gear does more than just show them how to do it right, it is actually quite an important almost sort of bonding experience between employees. It says I'm not
RE: Common operational misconceptions
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
Mark Grigsby m...@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: jensl...@guug.de | --- | -
Re: Common operational misconceptions
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
Mathias Wolkert t...@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: jensl...@guug.de | --- | -
RE: Common operational misconceptions
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 time-management mistake: rack stack
Jeff Wheeler j...@inconcepts.biz writes: With apologies to Randy, let the CCNAs fight with label makers. Yeah. And you need do be at last CCNP to switch a module in a router. Had this request last year. I first thought that some troubleshooting / configuration was involved but it was just replacing a module. Jens -- - | Foelderichstr. 40 | 13595 Berlin, Germany| +49-151-18721264 | | http://blog.quux.de | jabber: jensl...@guug.de | --- | -
RE: Spam from Telx
So, anyone else get spammed by Telx after posting to nanog? This is massively unprofessional. Nick Yep. I shot a complaint to customerserv...@telx.com. Assuming Mr. Fitzpatrick does not control that portion of the company, it may be of value for other recipients of his spam to do the same. Nathan Eisenberg
Re: Common operational misconceptions
On Fri, 17 Feb 2012, Jens Link wrote: Mathias Wolkert t...@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: jensl...@guug.de | --- | -
Re: Common operational misconceptions
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
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 time-management mistake: rack stack
On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler j...@inconcepts.biz wrote: ... Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. There is a theory of management that says a good manager needs to know nothing about the staff or the jobs he is managing, because his job is about returning profit to the shareholder, and not about what the company does. AFAIK, these theories are made in the academic halls of the business schools, which churn out MBAs, and, self-selected group that they are, believe in (more) managers, and (more) powerpoint business plans, and (more) theory. I happen to come from a different background, and believe that it has value to understand what the people who are working for you actually do. That does not mean the CEO should spend all day delivering the mail (or flipping burgers), but she had better have done it a few times, and it is a good idea to do it from time to time to see what has changed. It keeps the manager grounded with the reality. (I have been told that the reason that the commanders in the Army are reluctant to send their people to battle is that they have experienced it, and know it is hell. And the reason the people will go to hell for their commander is that the commander has the moral authority of having done it, experienced it, know that they are asking a lot, but it is for the common good. People will follow a leader who has been there, done that, and not so much when it is just an academic business plan on a powerpoint slide.)
Re: Common operational misconceptions
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 time-management mistake: rack stack
On Feb 16, 2012, at 11:29 PM, Jeff Wheeler wrote: Randy's P-Touch thread brings up an issue I think is worth some discussion. I have noticed that a lot of very well-paid, sometimes well-qualified, networking folks spend some of their time on rack stack tasks, which I feel is a very unwise use of time and talent. Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. Not only does the router jockey cost a lot more to employ than a CCNA, but if your senior-level talent is wasting time in airports and IBXes, that is time they can't be doing things CCNAs can't. I was once advising a client on a transit purchasing decision, and a fairly-large, now-defunct tier-2 ISP was being considered. We needed a few questions about their IPv6 plans answered before we were comfortable. The CTO of that org was the only guy who was able to answer these questions. After waiting four days for him to return our message, he reached out to us from an airplane phone, telling us that he had been busy racking new routers in several east-coast cities (his office was not east-coast) and that's why he hadn't got back to us yet. As you might imagine, the client quickly realized that they didn't want to deal with a vendor whose CTO spent his time doing rack stack instead of engineering his network or engaging with customers. If he had simply said he was on vacation, we would never have known how poorly the senior people at that ISP managed their time. With apologies to Randy, let the CCNAs fight with label makers. -- Jeff S Wheeler j...@inconcepts.biz Sr Network Operator / Innovative Network Concepts With all due respect, Jeff, I think you are missing several factors that come into the human equation beyond merely the most efficient use of a particular person's time. I would go stark-raving bonkers trapped in a cubicle doing only things that CCNAs can't if I didn't get the occasional break to go out and play with real hardware in the field. Most of the well-paid well-qualified networking folks I know are the same way. I also think that when we spend too many consecutive weeks/months/years behind a desk without going out in the real world, we become progressively more detached from the operational reality where our designs have to operate. On the surface, it might seem an inefficient use of financial/human resources, but, I think that there is value to time in the field that doesn't necessarily show up directly on the balance sheet. Admittedly, in my current position, I'm no longer in an operational role for the most part, but, I'm even more out in the field and spending more time in airports. Owen
Re: Hi speed trading - hi speed monitoring
On Feb 17, 2012, at 10:30 AM, Jay Ashworth j...@baylink.com wrote: - Original Message - From: Paul Graydon p...@paulgraydon.co.uk Anecdotally, I had an interview years ago for a small-ish futures trading company based in London. The interviewer had to pause the interview part way through whilst he investigated a 10ms latency spike that the traders were noticing on a short point-to-point fiber link to the London Stock Exchange. He commented that the traders were far better at 'feeling' when an connection was showing even a trace of lag compared to normal than anything he'd set up by way of monitoring (not sure how good his monitoring was, though.) This was my experience in a callcenter as well; network type problem reports always came in from the floor managers before Nagios came forth with an opinion. This has nothing to do with a gut feeling or instinct. Trading companies today monitor PL near realtime and traders will begin to experience low fill rates or worse be rejected by trading counter parties when prices are too far off or out of the money. The longer a system takes to responds to market quotes the lower fills rates they begin to notice and higher execution costs. Trades today in the equity markets must be within the national best bid, best offer price range or companies can be fined by the SEC which is why latency an jitter can be problematic in financial networks. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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
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 s...@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
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: Anonymous planning a root-servers party
- Original Message - From: Sven Olaf Kamphuis s...@cb3rob.net the internet treats censorship as damage and routes around it, remember that one :P Not only do we remember it, I believe John's on this list. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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 time-management mistake: rack stack
From: Gary Buhrmaster [mailto:gary.buhrmas...@gmail.com] Sent: Friday, February 17, 2012 12:54 PM To: Jeff Wheeler Cc: NANOG Subject: Re: common time-management mistake: rack stack On Thu, Feb 16, 2012 at 23:29, Jeff Wheeler j...@inconcepts.biz wrote: ... Imagine if the CFO of a bank spent a big chunk of his time filling up ATMs. Flying a sharp router jockey around to far-flung POPs to install gear is just as foolish. There is a theory of management that says a good manager needs to know nothing about the staff or the jobs he is managing, because his job is about returning profit to the shareholder, and not about what the company does. AFAIK, these theories are made in the academic halls of the business schools, which churn out MBAs, and, self-selected group that they are, believe in (more) managers, and (more) powerpoint business plans, and (more) theory. I happen to come from a different background, and believe that it has value to understand what the people who are working for you actually do. That does not mean the CEO should spend all day delivering the mail (or flipping burgers), but she had better have done it a few times, and it is a good idea to do it from time to time to see what has changed. It keeps the manager grounded with the reality. (I have been told that the reason that the commanders in the Army are reluctant to send their people to battle is that they have experienced it, and know it is hell. And the reason the people will go to hell for their commander is that the commander has the moral authority of having done it, experienced it, know that they are asking a lot, but it is for the common good. People will follow a leader who has been there, done that, and not so much when it is just an academic business plan on a powerpoint slide.) +1 for Gary's comment. That is the large difference between LEADING and MANAGING. In the context of the military scenario above, Grace Hopper comes to mind because of her nanoseconds etc In her retirement speech, instead of dwelling on the past, she talked about moving toward the future, stressing the importance of leadership. http://inventors.about.com/od/hstartinventors/a/Grace_Hopper_2.htm I was lucky enough to have heard her speak once at an ACM event. Tony Patti CIO S. Walter Packaging Corp.
Re: common time-management mistake: rack stack
- Original Message - From: Leo Bicknell bickn...@ufp.org Maybe if we did more apprecenship style learning folks would still know how to wrap cables with wax string. It's simple, fast, and works well. Cue the obligatory cabling porn thread. Cheers, -- jr 'and aren't all the old Bell guys dead now?' a -- Jay R. Ashworth Baylink j...@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 a message written on Fri, Feb 17, 2012 at 06:06:52PM +, 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 - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgpTvd8Rspgq8.pgp Description: PGP signature
Re: Common operational misconceptions
- Original Message - From: Mike Andrews mi...@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 j...@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
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.bra...@pateam.com 5095 Ritter Rd Mechanicsburg PA 17055 -Original Message- From: Scott Helms [mailto:khe...@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
Leo Bicknell bickn...@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: jensl...@guug.de | --- | -
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
WW: Colo Vending Machine
Please post your top 3 favorite components/parts you'd like to see in a vending machine at your colo; please be as specific as possible; don't let vendor specificity scare you off. Cheers, -- jra -- Jay R. Ashworth Baylink j...@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: WW: Colo Vending Machine
On Fri, Feb 17, 2012 at 10:35 AM, Jay Ashworth j...@baylink.com wrote: Please post your top 3 favorite components/parts you'd like to see in a vending machine at your colo; please be as specific as possible; don't let vendor specificity scare you off. This is a riot! I'd love to have something like this at facilities I'm in. Some useful stuff that comes to mind: - Rack screws of various common sizes and threadings - SFPs, GBICs, etc. - Rollover cable / DE-9-8P8P adapter - Screwdrivers - Cross-over Ethernet, patch cables - zip ties, velcro tape, etc. - Label tape Cheers, jof
Re: WW: Colo Vending Machine
On 2/17/12 10:35 AM, Jay Ashworth wrote: Please post your top 3 favorite components/parts you'd like to see in a vending machine at your colo; please be as specific as possible; don't let vendor specificity scare you off. Clue in a Can - I prefer the 8 oz size, but sometimes it would be nice to get the 12 oz bottle. --tep
Re: Common operational misconceptions
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: WW: Colo Vending Machine
On Fri, 17 Feb 2012, Jay Ashworth wrote: Please post your top 3 favorite components/parts you'd like to see in a vending machine at your colo; please be as specific as possible; don't let vendor specificity scare you off. 1. 1GB+ USB sticks 2. Cat5E patch cords in various lengths 3. Rack screws/cage nuts that are appropriate for the types of cabinets in that facility jms
