<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article09_12_24_223217</id>
	<title>Testing Network Changes When No Test Labs Exist?</title>
	<author>timothy</author>
	<datestamp>1261653240000</datestamp>
	<htmltext>vvaduva writes <i>"The ugly truth is that many network guys secretly work on production equipment all the time, or test things on production networks when they face impossible deadlines.  Management often expects us to get a job done but refuse to provide funds for expensive lab equipment, test circuits and for reasonable time to get testing done before moving equipment or configs into production.  How do most of you handle such situations, and what recommendation do you have for creating a network test lab on the cheap, especially when core network devices are vendor-centric, like Cisco?"</i></htmltext>
<tokenext>vvaduva writes " The ugly truth is that many network guys secretly work on production equipment all the time , or test things on production networks when they face impossible deadlines .
Management often expects us to get a job done but refuse to provide funds for expensive lab equipment , test circuits and for reasonable time to get testing done before moving equipment or configs into production .
How do most of you handle such situations , and what recommendation do you have for creating a network test lab on the cheap , especially when core network devices are vendor-centric , like Cisco ?
"</tokentext>
<sentencetext>vvaduva writes "The ugly truth is that many network guys secretly work on production equipment all the time, or test things on production networks when they face impossible deadlines.
Management often expects us to get a job done but refuse to provide funds for expensive lab equipment, test circuits and for reasonable time to get testing done before moving equipment or configs into production.
How do most of you handle such situations, and what recommendation do you have for creating a network test lab on the cheap, especially when core network devices are vendor-centric, like Cisco?
"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548736</id>
	<title>Only a matter of time</title>
	<author>w00ten</author>
	<datestamp>1261670220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>It's only a matter of time until a change that wasn't properly tested completely screws everything up and some exec is lookin at you for answers. I've learned that the best interpersonal skill to have is deflection. Nice guys finish last, especially in a corporate environment, so try to get test equipment and when they say no, like all companies do, SAVE IT so you can blame someone else! This is what you can send to the CTO when he asks why you didn't properly test the changes that caused the company to lose millions of dollars in operating costs cause the network was down for 6 hours. "well, I warned people in this email trail and proposal, but they shot me down, and I was right". If by some incredible miracle this never has to happen, then count your lucky stars and when they ask why nothing has gone wrong, toot your own horn and say that it's because you are so damn good. No matter what, you show value, you secure your position. As for basic testing, any of the programs mentioned here will work, Packet Tracer is limited in the models it supports so you might want to look at something else first.</htmltext>
<tokenext>It 's only a matter of time until a change that was n't properly tested completely screws everything up and some exec is lookin at you for answers .
I 've learned that the best interpersonal skill to have is deflection .
Nice guys finish last , especially in a corporate environment , so try to get test equipment and when they say no , like all companies do , SAVE IT so you can blame someone else !
This is what you can send to the CTO when he asks why you did n't properly test the changes that caused the company to lose millions of dollars in operating costs cause the network was down for 6 hours .
" well , I warned people in this email trail and proposal , but they shot me down , and I was right " .
If by some incredible miracle this never has to happen , then count your lucky stars and when they ask why nothing has gone wrong , toot your own horn and say that it 's because you are so damn good .
No matter what , you show value , you secure your position .
As for basic testing , any of the programs mentioned here will work , Packet Tracer is limited in the models it supports so you might want to look at something else first .</tokentext>
<sentencetext>It's only a matter of time until a change that wasn't properly tested completely screws everything up and some exec is lookin at you for answers.
I've learned that the best interpersonal skill to have is deflection.
Nice guys finish last, especially in a corporate environment, so try to get test equipment and when they say no, like all companies do, SAVE IT so you can blame someone else!
This is what you can send to the CTO when he asks why you didn't properly test the changes that caused the company to lose millions of dollars in operating costs cause the network was down for 6 hours.
"well, I warned people in this email trail and proposal, but they shot me down, and I was right".
If by some incredible miracle this never has to happen, then count your lucky stars and when they ask why nothing has gone wrong, toot your own horn and say that it's because you are so damn good.
No matter what, you show value, you secure your position.
As for basic testing, any of the programs mentioned here will work, Packet Tracer is limited in the models it supports so you might want to look at something else first.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30554272</id>
	<title>Re:Document and test at night</title>
	<author>vaniderstine</author>
	<datestamp>1261765380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Your statement is mostly true.  Unfortunately, management will remove your budget if it goes too well.  And production engineers will only comment on your networks' stability after it starts going to hell again.</htmltext>
<tokenext>Your statement is mostly true .
Unfortunately , management will remove your budget if it goes too well .
And production engineers will only comment on your networks ' stability after it starts going to hell again .</tokentext>
<sentencetext>Your statement is mostly true.
Unfortunately, management will remove your budget if it goes too well.
And production engineers will only comment on your networks' stability after it starts going to hell again.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548224</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548098</id>
	<title>Plan, inform and be prepared!</title>
	<author>Anonymous</author>
	<datestamp>1261659840000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Been there, done that (A LOT!!)<br>But it has failed quite a few times too..</p><p>If no money available for test labs, make good plans... Tell the dudes that wanted the changes (or if you are the dude that wants the changes inform the correct people that you will be doing stuff) Agree on a service window. Have backup plans.. Have all configurations saved.. Let all users know that after 10pm on that saturday network will be down for 10 mins etc etc..</p><p>Have tons of contengency plans, and let the 'responsible' people known what you are about to do.. Plan everything 'wide'... So even a 5 mins cable plugover, reserve a service window outside of office hours for 2 hours..</p></htmltext>
<tokenext>Been there , done that ( A LOT ! !
) But it has failed quite a few times too..If no money available for test labs , make good plans... Tell the dudes that wanted the changes ( or if you are the dude that wants the changes inform the correct people that you will be doing stuff ) Agree on a service window .
Have backup plans.. Have all configurations saved.. Let all users know that after 10pm on that saturday network will be down for 10 mins etc etc..Have tons of contengency plans , and let the 'responsible ' people known what you are about to do.. Plan everything 'wide'... So even a 5 mins cable plugover , reserve a service window outside of office hours for 2 hours. .</tokentext>
<sentencetext>Been there, done that (A LOT!!
)But it has failed quite a few times too..If no money available for test labs, make good plans... Tell the dudes that wanted the changes (or if you are the dude that wants the changes inform the correct people that you will be doing stuff) Agree on a service window.
Have backup plans.. Have all configurations saved.. Let all users know that after 10pm on that saturday network will be down for 10 mins etc etc..Have tons of contengency plans, and let the 'responsible' people known what you are about to do.. Plan everything 'wide'... So even a 5 mins cable plugover, reserve a service window outside of office hours for 2 hours..</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30555562</id>
	<title>Do it the olde fashioned way</title>
	<author>Anonymous</author>
	<datestamp>1261840620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Calculate CPU cycles, read the source code, understand your changes, and roll them out. Oh wait! You're using Cisco, nevermind.</p></htmltext>
<tokenext>Calculate CPU cycles , read the source code , understand your changes , and roll them out .
Oh wait !
You 're using Cisco , nevermind .</tokentext>
<sentencetext>Calculate CPU cycles, read the source code, understand your changes, and roll them out.
Oh wait!
You're using Cisco, nevermind.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30550322</id>
	<title>Reuse DR network equipment</title>
	<author>Anonymous</author>
	<datestamp>1261745340000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Our company purchases DR equipment for our network hardware.  Thus if a switch in the data center blows out we can replace it very quickly.</p><p>Instead of leaving it on the shelf we hook it up and use it for test environments.  If production needs a replacement we drop the test environment and put the DR in place.</p><p>Costs more upfront but makes good use out of the equipment.</p></htmltext>
<tokenext>Our company purchases DR equipment for our network hardware .
Thus if a switch in the data center blows out we can replace it very quickly.Instead of leaving it on the shelf we hook it up and use it for test environments .
If production needs a replacement we drop the test environment and put the DR in place.Costs more upfront but makes good use out of the equipment .</tokentext>
<sentencetext>Our company purchases DR equipment for our network hardware.
Thus if a switch in the data center blows out we can replace it very quickly.Instead of leaving it on the shelf we hook it up and use it for test environments.
If production needs a replacement we drop the test environment and put the DR in place.Costs more upfront but makes good use out of the equipment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548674</id>
	<title>Re:The tag says it all</title>
	<author>Anonymous</author>
	<datestamp>1261669140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I agree, I am currently moving away from Cisco to JUNOS and I am loving it.</p></htmltext>
<tokenext>I agree , I am currently moving away from Cisco to JUNOS and I am loving it .</tokentext>
<sentencetext>I agree, I am currently moving away from Cisco to JUNOS and I am loving it.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364</id>
	<title>Download vyatta</title>
	<author>Sxooter</author>
	<datestamp>1261663560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Download an iso from Vyatta and build a test network with old PCs and spare NICs for testing.  Sure, it's not the exact same as Cisco, but if they're too cheap to buy the real thing for a test lab then you'll at least be somewhat close.</p><p>Then, once you realize what you're not getting for your money with Cisco, you can buyt $1000 1U servers and build your own routers (or buy them prebuilt from Vyatta for about $2000) to replace the ciscos and make a profit selling the used Ciscos on ebay.</p><p>I do NOT work for nor am I affiliated with Vyatta.  But their gear is pretty impressive, and open source.</p></htmltext>
<tokenext>Download an iso from Vyatta and build a test network with old PCs and spare NICs for testing .
Sure , it 's not the exact same as Cisco , but if they 're too cheap to buy the real thing for a test lab then you 'll at least be somewhat close.Then , once you realize what you 're not getting for your money with Cisco , you can buyt $ 1000 1U servers and build your own routers ( or buy them prebuilt from Vyatta for about $ 2000 ) to replace the ciscos and make a profit selling the used Ciscos on ebay.I do NOT work for nor am I affiliated with Vyatta .
But their gear is pretty impressive , and open source .</tokentext>
<sentencetext>Download an iso from Vyatta and build a test network with old PCs and spare NICs for testing.
Sure, it's not the exact same as Cisco, but if they're too cheap to buy the real thing for a test lab then you'll at least be somewhat close.Then, once you realize what you're not getting for your money with Cisco, you can buyt $1000 1U servers and build your own routers (or buy them prebuilt from Vyatta for about $2000) to replace the ciscos and make a profit selling the used Ciscos on ebay.I do NOT work for nor am I affiliated with Vyatta.
But their gear is pretty impressive, and open source.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548904</id>
	<title>Re:Pretty simple, really</title>
	<author>Marxist Hacker 42</author>
	<datestamp>1261672920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Either that, or redundancy, redundancy, redundancy.  I always at least try to convince the bosses that hardware needs to be ordered in even numbers- so that we have onsite emergency replacements.</p><p>That extra hardware can then be used to build test beds.</p></htmltext>
<tokenext>Either that , or redundancy , redundancy , redundancy .
I always at least try to convince the bosses that hardware needs to be ordered in even numbers- so that we have onsite emergency replacements.That extra hardware can then be used to build test beds .</tokentext>
<sentencetext>Either that, or redundancy, redundancy, redundancy.
I always at least try to convince the bosses that hardware needs to be ordered in even numbers- so that we have onsite emergency replacements.That extra hardware can then be used to build test beds.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548830</id>
	<title>Re:The tag says it all</title>
	<author>Stripe7</author>
	<datestamp>1261671720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Pen and paper analysis may not find out all the issues. We had a weird one that flummoxed a bunch of network engineers. It was an IOS upgrade to the built in fiber bridge on a blade server. The old IOS worked fine, the new one worked until you tried to jumpstart a blade. Jumpstarts worked fine with the old IOS but not on the new one. As we rarely jumpstarted the blades, this issue was not caught until after the bridges on all the blade servers were upgraded.</htmltext>
<tokenext>Pen and paper analysis may not find out all the issues .
We had a weird one that flummoxed a bunch of network engineers .
It was an IOS upgrade to the built in fiber bridge on a blade server .
The old IOS worked fine , the new one worked until you tried to jumpstart a blade .
Jumpstarts worked fine with the old IOS but not on the new one .
As we rarely jumpstarted the blades , this issue was not caught until after the bridges on all the blade servers were upgraded .</tokentext>
<sentencetext>Pen and paper analysis may not find out all the issues.
We had a weird one that flummoxed a bunch of network engineers.
It was an IOS upgrade to the built in fiber bridge on a blade server.
The old IOS worked fine, the new one worked until you tried to jumpstart a blade.
Jumpstarts worked fine with the old IOS but not on the new one.
As we rarely jumpstarted the blades, this issue was not caught until after the bridges on all the blade servers were upgraded.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30565636</id>
	<title>Re:The tag says it all</title>
	<author>bobp0303</author>
	<datestamp>1261909140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Back in the 1980s we did everything on the live network at Cable &amp; Wireless -- of course, the company no longer exists in the United States, but I'm sure there's no connection there.  I remember chewing out the Vice President big-time -- didn't get fired, but didn't change anything either...</htmltext>
<tokenext>Back in the 1980s we did everything on the live network at Cable &amp; Wireless -- of course , the company no longer exists in the United States , but I 'm sure there 's no connection there .
I remember chewing out the Vice President big-time -- did n't get fired , but did n't change anything either.. .</tokentext>
<sentencetext>Back in the 1980s we did everything on the live network at Cable &amp; Wireless -- of course, the company no longer exists in the United States, but I'm sure there's no connection there.
I remember chewing out the Vice President big-time -- didn't get fired, but didn't change anything either...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548000</id>
	<title>Re:Document and test at night</title>
	<author>Keruo</author>
	<datestamp>1261658820000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>step 3) If possible test network changes on the production equipment at 2am so that impact on users will be less</p></div><p>Been there, done that. Sadly the only way to see how your setup works is to try it in production.<br>Sure it helps if you can test it beforehand, but sometimes your lab might not reflect what happens in real network when you roll something out.<br>
Just make sure you can clock those am hours as overtime/nighttime work. <br>
And remember to backup the running config twice so you can restore the production network if something goes fubar.</p></div>
	</htmltext>
<tokenext>step 3 ) If possible test network changes on the production equipment at 2am so that impact on users will be lessBeen there , done that .
Sadly the only way to see how your setup works is to try it in production.Sure it helps if you can test it beforehand , but sometimes your lab might not reflect what happens in real network when you roll something out .
Just make sure you can clock those am hours as overtime/nighttime work .
And remember to backup the running config twice so you can restore the production network if something goes fubar .</tokentext>
<sentencetext>step 3) If possible test network changes on the production equipment at 2am so that impact on users will be lessBeen there, done that.
Sadly the only way to see how your setup works is to try it in production.Sure it helps if you can test it beforehand, but sometimes your lab might not reflect what happens in real network when you roll something out.
Just make sure you can clock those am hours as overtime/nighttime work.
And remember to backup the running config twice so you can restore the production network if something goes fubar.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548510</id>
	<title>Re:Document and test at night</title>
	<author>timmarhy</author>
	<datestamp>1261666440000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>yep, and the other fail here is that a lot of production environments are 24/7. there is NOT a slow point, ever.</htmltext>
<tokenext>yep , and the other fail here is that a lot of production environments are 24/7 .
there is NOT a slow point , ever .</tokentext>
<sentencetext>yep, and the other fail here is that a lot of production environments are 24/7.
there is NOT a slow point, ever.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548388</id>
	<title>Get it in writing, let it fail.</title>
	<author>timmarhy</author>
	<datestamp>1261663800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Make your objections in writing, email it to the manager demanding the change you believe to place production at risk with the risks clearly outlined in bullet points. if he then insists you proceed, make him send you the request in writing/email and print out a duplicate, keep it in a safe place and then make his change. This way he owns the failure, not you. paper trails exist for a reason, to cover arses, and arse covering is often a worthwhile exercise.</htmltext>
<tokenext>Make your objections in writing , email it to the manager demanding the change you believe to place production at risk with the risks clearly outlined in bullet points .
if he then insists you proceed , make him send you the request in writing/email and print out a duplicate , keep it in a safe place and then make his change .
This way he owns the failure , not you .
paper trails exist for a reason , to cover arses , and arse covering is often a worthwhile exercise .</tokentext>
<sentencetext>Make your objections in writing, email it to the manager demanding the change you believe to place production at risk with the risks clearly outlined in bullet points.
if he then insists you proceed, make him send you the request in writing/email and print out a duplicate, keep it in a safe place and then make his change.
This way he owns the failure, not you.
paper trails exist for a reason, to cover arses, and arse covering is often a worthwhile exercise.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548178</id>
	<title>Some pointers</title>
	<author>pehrs</author>
	<datestamp>1261661040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It depends a lot on your environment and the complexity you are dealing with. Test labs are wonderful things, but typically you end up in a situation where your network is so limited that a lab won't help much, or your network simply too complex to create a sane lab environment without dedicated staff and a huge budget.</p><p>Building a full scale lab is a large undertaking. It takes time and effort. You will need taps (for routing information), traffic generators, topology management and more. In my experience it's usually better to have a smaller testbed that is used to test large changes before deployment and design your network so it's resilient to configuration mistakes.</p><p>Getting funding for a limited testbed is also much easier than a full lab, and you can do a lot of testing by simply stuffing a few routers in a rack and connecting it to the network management system.  Virtualization is something a lot of people will mention. It's useful, but it's hard to build anything resembling a modern network on top of it. You want hardware that resembles what you use in the network. Sometimes you can scavenge such hardware during upgrades, which can provide you with a basic testbed to build from.</p></htmltext>
<tokenext>It depends a lot on your environment and the complexity you are dealing with .
Test labs are wonderful things , but typically you end up in a situation where your network is so limited that a lab wo n't help much , or your network simply too complex to create a sane lab environment without dedicated staff and a huge budget.Building a full scale lab is a large undertaking .
It takes time and effort .
You will need taps ( for routing information ) , traffic generators , topology management and more .
In my experience it 's usually better to have a smaller testbed that is used to test large changes before deployment and design your network so it 's resilient to configuration mistakes.Getting funding for a limited testbed is also much easier than a full lab , and you can do a lot of testing by simply stuffing a few routers in a rack and connecting it to the network management system .
Virtualization is something a lot of people will mention .
It 's useful , but it 's hard to build anything resembling a modern network on top of it .
You want hardware that resembles what you use in the network .
Sometimes you can scavenge such hardware during upgrades , which can provide you with a basic testbed to build from .</tokentext>
<sentencetext>It depends a lot on your environment and the complexity you are dealing with.
Test labs are wonderful things, but typically you end up in a situation where your network is so limited that a lab won't help much, or your network simply too complex to create a sane lab environment without dedicated staff and a huge budget.Building a full scale lab is a large undertaking.
It takes time and effort.
You will need taps (for routing information), traffic generators, topology management and more.
In my experience it's usually better to have a smaller testbed that is used to test large changes before deployment and design your network so it's resilient to configuration mistakes.Getting funding for a limited testbed is also much easier than a full lab, and you can do a lot of testing by simply stuffing a few routers in a rack and connecting it to the network management system.
Virtualization is something a lot of people will mention.
It's useful, but it's hard to build anything resembling a modern network on top of it.
You want hardware that resembles what you use in the network.
Sometimes you can scavenge such hardware during upgrades, which can provide you with a basic testbed to build from.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970</id>
	<title>Re:The tag says it all</title>
	<author>Anonymous</author>
	<datestamp>1261658520000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Not Pushing Juniper gear, but their Commit functions in JUNOS, and commands like "rollback" are serious things to consider in these scenarios. JUNOS also does things like refusing to perform a commit if you've done something obviously stupid (it does basic checking of your config when you commit).</p><p>Label me a shill. Whatever. JUNOS is a lot better from an operator POV.</p></htmltext>
<tokenext>Not Pushing Juniper gear , but their Commit functions in JUNOS , and commands like " rollback " are serious things to consider in these scenarios .
JUNOS also does things like refusing to perform a commit if you 've done something obviously stupid ( it does basic checking of your config when you commit ) .Label me a shill .
Whatever. JUNOS is a lot better from an operator POV .</tokentext>
<sentencetext>Not Pushing Juniper gear, but their Commit functions in JUNOS, and commands like "rollback" are serious things to consider in these scenarios.
JUNOS also does things like refusing to perform a commit if you've done something obviously stupid (it does basic checking of your config when you commit).Label me a shill.
Whatever. JUNOS is a lot better from an operator POV.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548514</id>
	<title>Re:Document and test at night</title>
	<author>BiggerIsBetter</author>
	<datestamp>1261666500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>3) If possible test network changes on the production equipment at 2am so that impact on users will be less step</p></div><p>You're a network guy, right? How well do you know the applications that use your network? How sure are you that the application behind, or in front of the change you're making don't need a restart after losing connectivity? Maybe your late night tests are causing all sorts of problems and expense when the apps guys come in to find the system inexplicably down, having visible outages, and have to start raising support requests against vendors to find a solution to their non-reproducible high severity defect in production? Don't do that.</p></div>
	</htmltext>
<tokenext>3 ) If possible test network changes on the production equipment at 2am so that impact on users will be less stepYou 're a network guy , right ?
How well do you know the applications that use your network ?
How sure are you that the application behind , or in front of the change you 're making do n't need a restart after losing connectivity ?
Maybe your late night tests are causing all sorts of problems and expense when the apps guys come in to find the system inexplicably down , having visible outages , and have to start raising support requests against vendors to find a solution to their non-reproducible high severity defect in production ?
Do n't do that .</tokentext>
<sentencetext>3) If possible test network changes on the production equipment at 2am so that impact on users will be less stepYou're a network guy, right?
How well do you know the applications that use your network?
How sure are you that the application behind, or in front of the change you're making don't need a restart after losing connectivity?
Maybe your late night tests are causing all sorts of problems and expense when the apps guys come in to find the system inexplicably down, having visible outages, and have to start raising support requests against vendors to find a solution to their non-reproducible high severity defect in production?
Don't do that.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548500</id>
	<title>Re:Document and test at night</title>
	<author>SharpFang</author>
	<datestamp>1261666320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>3) If possible test network changes on the production equipment at 2am so that impact on users will be less step</p><p>That's dangerous. You leave it apparently running and crawl back to sleep at 4:30AM, to get an angry call at 7:05AM when the first users to log in report something essential is fucked up.</p><p>Prepare and test at 2AM, then roll back to original. Then re-apply around lunch break and wait with your fingers on roll-back for the first reports of failure.</p></htmltext>
<tokenext>3 ) If possible test network changes on the production equipment at 2am so that impact on users will be less stepThat 's dangerous .
You leave it apparently running and crawl back to sleep at 4 : 30AM , to get an angry call at 7 : 05AM when the first users to log in report something essential is fucked up.Prepare and test at 2AM , then roll back to original .
Then re-apply around lunch break and wait with your fingers on roll-back for the first reports of failure .</tokentext>
<sentencetext>3) If possible test network changes on the production equipment at 2am so that impact on users will be less stepThat's dangerous.
You leave it apparently running and crawl back to sleep at 4:30AM, to get an angry call at 7:05AM when the first users to log in report something essential is fucked up.Prepare and test at 2AM, then roll back to original.
Then re-apply around lunch break and wait with your fingers on roll-back for the first reports of failure.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547886</id>
	<title>My last resort</title>
	<author>tchdab1</author>
	<datestamp>1261657620000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>I call my buddies at RIM and test my mods on their system.</p></htmltext>
<tokenext>I call my buddies at RIM and test my mods on their system .</tokentext>
<sentencetext>I call my buddies at RIM and test my mods on their system.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549520</id>
	<title>Before you do anything.......</title>
	<author>Kr1ll1n</author>
	<datestamp>1261682340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext>first, pick the closest site that is drive-able to test with first.

Make sure you have included a method for accessing the site in case of failure.....Dial-in modem, additional access path.....Even if it weakens security, you can remove it after you have verified the changes as working...Trust me on this. I have overseen Cisco networks that were remote ranging from 30+ sites to 300+ sites, all in distances that were not going to be approved to drive to.</htmltext>
<tokenext>first , pick the closest site that is drive-able to test with first .
Make sure you have included a method for accessing the site in case of failure.....Dial-in modem , additional access path.....Even if it weakens security , you can remove it after you have verified the changes as working...Trust me on this .
I have overseen Cisco networks that were remote ranging from 30 + sites to 300 + sites , all in distances that were not going to be approved to drive to .</tokentext>
<sentencetext>first, pick the closest site that is drive-able to test with first.
Make sure you have included a method for accessing the site in case of failure.....Dial-in modem, additional access path.....Even if it weakens security, you can remove it after you have verified the changes as working...Trust me on this.
I have overseen Cisco networks that were remote ranging from 30+ sites to 300+ sites, all in distances that were not going to be approved to drive to.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548776</id>
	<title>try clownix</title>
	<author>peril</author>
	<datestamp>1261670940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>http://www.clownix.net</p><p>I did a write-up on this product in the beginning of this month - can run quagga routers in the UML image of your choice - wrote / ran a 12 router lab that ran on a p4 with 512MB / RAM. (http://www.vlcg.net/content/cloonix-clownix-rocks)</p><p>If this product was used - you would only be able to functionally test the protocols in a particular topology - wouldn't be cisco, and it wouldn't be the same as production (different protocols, different topologies).</p><p>I discovered this trying to figure out a way to run quagga in a gns3-like setup. GNS3 is great for testing a specific cisco thing that you need to learn about - but it didn't do well for me beyond 3 routers - (too much hand-holding getting the environment tweaked).</p><p>My ultimate vision for quagga would be to run it on the hypervisor and let it scale (in numbers of routing instances) wrt to the number of hypervisors - it's a pipe dream for now, but I think that routing that can scale with hypervisors is going to be a big challenge for cisco (esp if they try to do it in silicon) -</p><p>--Adrian</p></htmltext>
<tokenext>http : //www.clownix.netI did a write-up on this product in the beginning of this month - can run quagga routers in the UML image of your choice - wrote / ran a 12 router lab that ran on a p4 with 512MB / RAM .
( http : //www.vlcg.net/content/cloonix-clownix-rocks ) If this product was used - you would only be able to functionally test the protocols in a particular topology - would n't be cisco , and it would n't be the same as production ( different protocols , different topologies ) .I discovered this trying to figure out a way to run quagga in a gns3-like setup .
GNS3 is great for testing a specific cisco thing that you need to learn about - but it did n't do well for me beyond 3 routers - ( too much hand-holding getting the environment tweaked ) .My ultimate vision for quagga would be to run it on the hypervisor and let it scale ( in numbers of routing instances ) wrt to the number of hypervisors - it 's a pipe dream for now , but I think that routing that can scale with hypervisors is going to be a big challenge for cisco ( esp if they try to do it in silicon ) ---Adrian</tokentext>
<sentencetext>http://www.clownix.netI did a write-up on this product in the beginning of this month - can run quagga routers in the UML image of your choice - wrote / ran a 12 router lab that ran on a p4 with 512MB / RAM.
(http://www.vlcg.net/content/cloonix-clownix-rocks)If this product was used - you would only be able to functionally test the protocols in a particular topology - wouldn't be cisco, and it wouldn't be the same as production (different protocols, different topologies).I discovered this trying to figure out a way to run quagga in a gns3-like setup.
GNS3 is great for testing a specific cisco thing that you need to learn about - but it didn't do well for me beyond 3 routers - (too much hand-holding getting the environment tweaked).My ultimate vision for quagga would be to run it on the hypervisor and let it scale (in numbers of routing instances) wrt to the number of hypervisors - it's a pipe dream for now, but I think that routing that can scale with hypervisors is going to be a big challenge for cisco (esp if they try to do it in silicon) ---Adrian</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548120</id>
	<title>Simulation</title>
	<author>Anonymous</author>
	<datestamp>1261660260000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>That is what simulation/network planning software is for. For example OPNET: http://www.opnet.com</p></htmltext>
<tokenext>That is what simulation/network planning software is for .
For example OPNET : http : //www.opnet.com</tokentext>
<sentencetext>That is what simulation/network planning software is for.
For example OPNET: http://www.opnet.com</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548902</id>
	<title>Re:Pretty simple, really</title>
	<author>Bruha</author>
	<datestamp>1261672800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's called a FOA first office application.  You do what modeling you can, check what you're changing and Rule #1 is dont fuck with something if you know nothing about it.  We do it in the middle of the night and if it screws up things we just restore the changed equipment to the pre change state.   Networks are too complex and even the best lab modeling does not catch all situations.</p></htmltext>
<tokenext>It 's called a FOA first office application .
You do what modeling you can , check what you 're changing and Rule # 1 is dont fuck with something if you know nothing about it .
We do it in the middle of the night and if it screws up things we just restore the changed equipment to the pre change state .
Networks are too complex and even the best lab modeling does not catch all situations .</tokentext>
<sentencetext>It's called a FOA first office application.
You do what modeling you can, check what you're changing and Rule #1 is dont fuck with something if you know nothing about it.
We do it in the middle of the night and if it screws up things we just restore the changed equipment to the pre change state.
Networks are too complex and even the best lab modeling does not catch all situations.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549048</id>
	<title>Re:Document and test at night</title>
	<author>Anonymous</author>
	<datestamp>1261675080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Step 3a: pull some tiles from the machine room floor, disconnect the lights and call the bean counter in for an "urgent meeting". Be sure to have plenty of quicklime handy...</p></htmltext>
<tokenext>Step 3a : pull some tiles from the machine room floor , disconnect the lights and call the bean counter in for an " urgent meeting " .
Be sure to have plenty of quicklime handy.. .</tokentext>
<sentencetext>Step 3a: pull some tiles from the machine room floor, disconnect the lights and call the bean counter in for an "urgent meeting".
Be sure to have plenty of quicklime handy...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30550474</id>
	<title>Services</title>
	<author>Alarash</author>
	<datestamp>1261748700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You hire Professional Services from a lab/test equipment manufacturer (Spirent, Ixia, BPS) or dedicated testing companies (EANTC or others). Most of them will accept to work during the night, so you need to get a "maintenance" window where they can inject traffic. I do that all the time, from the testers side. It's stupid to do, by the way, because you should always test *before* production.</p><p>But that's really dangerous and the best way is still to test in the "lab". A lab can be a temporary rack where you put test equipment you rent for a few days. Those test equipments can emulate very complex network topologies, so even if you have only, say, one firewall you need to test, you don't need the rest of the network devices in your lab (although it would be better, of course, but it's not mandatory). Most of the companies have at least one spare unit for their network equipments, to quickly replace them if they were to fail, so you could use that one for testing a new configuration before committing it to production. Again, not ideal, but definitively better than not testing. A nice blog to read about the importance of testing is <a href="http://www.spirent.com/Blog/Broadband/" title="spirent.com">Spirent's</a> [spirent.com].</p></htmltext>
<tokenext>You hire Professional Services from a lab/test equipment manufacturer ( Spirent , Ixia , BPS ) or dedicated testing companies ( EANTC or others ) .
Most of them will accept to work during the night , so you need to get a " maintenance " window where they can inject traffic .
I do that all the time , from the testers side .
It 's stupid to do , by the way , because you should always test * before * production.But that 's really dangerous and the best way is still to test in the " lab " .
A lab can be a temporary rack where you put test equipment you rent for a few days .
Those test equipments can emulate very complex network topologies , so even if you have only , say , one firewall you need to test , you do n't need the rest of the network devices in your lab ( although it would be better , of course , but it 's not mandatory ) .
Most of the companies have at least one spare unit for their network equipments , to quickly replace them if they were to fail , so you could use that one for testing a new configuration before committing it to production .
Again , not ideal , but definitively better than not testing .
A nice blog to read about the importance of testing is Spirent 's [ spirent.com ] .</tokentext>
<sentencetext>You hire Professional Services from a lab/test equipment manufacturer (Spirent, Ixia, BPS) or dedicated testing companies (EANTC or others).
Most of them will accept to work during the night, so you need to get a "maintenance" window where they can inject traffic.
I do that all the time, from the testers side.
It's stupid to do, by the way, because you should always test *before* production.But that's really dangerous and the best way is still to test in the "lab".
A lab can be a temporary rack where you put test equipment you rent for a few days.
Those test equipments can emulate very complex network topologies, so even if you have only, say, one firewall you need to test, you don't need the rest of the network devices in your lab (although it would be better, of course, but it's not mandatory).
Most of the companies have at least one spare unit for their network equipments, to quickly replace them if they were to fail, so you could use that one for testing a new configuration before committing it to production.
Again, not ideal, but definitively better than not testing.
A nice blog to read about the importance of testing is Spirent's [spirent.com].</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548092</id>
	<title>Borrow a lab!</title>
	<author>jimpop</author>
	<datestamp>1261659720000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>Cisco have many (large) labs located around the world.  Sign up for some time in one of them.</p></htmltext>
<tokenext>Cisco have many ( large ) labs located around the world .
Sign up for some time in one of them .</tokentext>
<sentencetext>Cisco have many (large) labs located around the world.
Sign up for some time in one of them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548240</id>
	<title>No, there's nothing wrong with that</title>
	<author>Rix</author>
	<datestamp>1261661640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As long as the downtime that will result is acceptable.</p></htmltext>
<tokenext>As long as the downtime that will result is acceptable .</tokentext>
<sentencetext>As long as the downtime that will result is acceptable.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547890</id>
	<title>Boson and VMware</title>
	<author>Zlurg</author>
	<datestamp>1261657680000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>Seriously, try and find as much virtual equipment as you can and replicate it as closely as possible to your production lab.  If you run one of the myriad sniffers on a VM, you might even come up with a clever way to send production traffic to your virtual lab.

There is no other way to do it.  You are screwed, so if you're serious, you can either buy the lab yourself or make one out of tin cans, coconuts and wet rope.</htmltext>
<tokenext>Seriously , try and find as much virtual equipment as you can and replicate it as closely as possible to your production lab .
If you run one of the myriad sniffers on a VM , you might even come up with a clever way to send production traffic to your virtual lab .
There is no other way to do it .
You are screwed , so if you 're serious , you can either buy the lab yourself or make one out of tin cans , coconuts and wet rope .</tokentext>
<sentencetext>Seriously, try and find as much virtual equipment as you can and replicate it as closely as possible to your production lab.
If you run one of the myriad sniffers on a VM, you might even come up with a clever way to send production traffic to your virtual lab.
There is no other way to do it.
You are screwed, so if you're serious, you can either buy the lab yourself or make one out of tin cans, coconuts and wet rope.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547858</id>
	<title>Could be worse</title>
	<author>7213</author>
	<datestamp>1261657320000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>The best bet is to be ready to blame the vendor when things go south<nobr> <wbr></nobr>;-)</p><p>Seriously, I'm right there with you. If management does not want to provide for a test lab &amp; reasonable time to test. Then it's clear they've made a 'business decision' that the network is not of sufficient value / risk is not great enough for such investments.</p><p>This may change quickly once something goes south (assuming they understand why it did) but you're gonna be talking to a brick wall until then.</p><p>It could be worse, you could have management that are afraid of there own shadows &amp; who freak out at the idea of replacing redundant components after a HW failure. (Ever had to get VP approval to replace a failed GBIC? Oh, I have &amp; yes, I hate my life).</p></htmltext>
<tokenext>The best bet is to be ready to blame the vendor when things go south ; - ) Seriously , I 'm right there with you .
If management does not want to provide for a test lab &amp; reasonable time to test .
Then it 's clear they 've made a 'business decision ' that the network is not of sufficient value / risk is not great enough for such investments.This may change quickly once something goes south ( assuming they understand why it did ) but you 're gon na be talking to a brick wall until then.It could be worse , you could have management that are afraid of there own shadows &amp; who freak out at the idea of replacing redundant components after a HW failure .
( Ever had to get VP approval to replace a failed GBIC ?
Oh , I have &amp; yes , I hate my life ) .</tokentext>
<sentencetext>The best bet is to be ready to blame the vendor when things go south ;-)Seriously, I'm right there with you.
If management does not want to provide for a test lab &amp; reasonable time to test.
Then it's clear they've made a 'business decision' that the network is not of sufficient value / risk is not great enough for such investments.This may change quickly once something goes south (assuming they understand why it did) but you're gonna be talking to a brick wall until then.It could be worse, you could have management that are afraid of there own shadows &amp; who freak out at the idea of replacing redundant components after a HW failure.
(Ever had to get VP approval to replace a failed GBIC?
Oh, I have &amp; yes, I hate my life).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548386</id>
	<title>UNH-IOL</title>
	<author>slugmass</author>
	<datestamp>1261663800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The UNH-IOL is a neutral, third-party laboratory dedicated to testing data networking technologies through industry collaboration.</p><p><a href="http://www.iol.unh.edu/" title="unh.edu" rel="nofollow">http://www.iol.unh.edu/</a> [unh.edu]</p></htmltext>
<tokenext>The UNH-IOL is a neutral , third-party laboratory dedicated to testing data networking technologies through industry collaboration.http : //www.iol.unh.edu/ [ unh.edu ]</tokentext>
<sentencetext>The UNH-IOL is a neutral, third-party laboratory dedicated to testing data networking technologies through industry collaboration.http://www.iol.unh.edu/ [unh.edu]</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551008</id>
	<title>Re:Pretty simple, really</title>
	<author>malachai</author>
	<datestamp>1261758780000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Marxist Hacker has the right idea.</p><p>When I pitched needing a lab, I was pretty quickly shot down since it was costs they couldn't see the benefit from.</p><p>Wait a month and pitch it again except this time from the aspect of downtime, redundant hardware diminishes this. Was an easy sell. And now, I have a second set of hardware I can test on.</p><p>Win.</p></htmltext>
<tokenext>Marxist Hacker has the right idea.When I pitched needing a lab , I was pretty quickly shot down since it was costs they could n't see the benefit from.Wait a month and pitch it again except this time from the aspect of downtime , redundant hardware diminishes this .
Was an easy sell .
And now , I have a second set of hardware I can test on.Win .</tokentext>
<sentencetext>Marxist Hacker has the right idea.When I pitched needing a lab, I was pretty quickly shot down since it was costs they couldn't see the benefit from.Wait a month and pitch it again except this time from the aspect of downtime, redundant hardware diminishes this.
Was an easy sell.
And now, I have a second set of hardware I can test on.Win.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548904</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548176</id>
	<title>Paper Trail</title>
	<author>tengu1sd</author>
	<datestamp>1261661040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><i>&gt;&gt;&gt;refuse to provide funds for expensive lab equipment, test circuits and for reasonable time to get testing done before moving equipment or configs into production.</i> <p>

Make sure that every change request implementation documents that <i>this change is being placed intro the production environment for testing</i>.  Document impact ranging from total network failure to moderate inconvenience and include roll out time tables.  The roll out needs include travel times such drive to site B or fly cross country.
</p><p>
Of course the downside of this is that management may go out and hire someone who knows, or at least pretends to know, how to drop changes into place without whining about ignorance and making customers uncomfortable.</p></htmltext>
<tokenext>&gt; &gt; &gt; refuse to provide funds for expensive lab equipment , test circuits and for reasonable time to get testing done before moving equipment or configs into production .
Make sure that every change request implementation documents that this change is being placed intro the production environment for testing .
Document impact ranging from total network failure to moderate inconvenience and include roll out time tables .
The roll out needs include travel times such drive to site B or fly cross country .
Of course the downside of this is that management may go out and hire someone who knows , or at least pretends to know , how to drop changes into place without whining about ignorance and making customers uncomfortable .</tokentext>
<sentencetext>&gt;&gt;&gt;refuse to provide funds for expensive lab equipment, test circuits and for reasonable time to get testing done before moving equipment or configs into production.
Make sure that every change request implementation documents that this change is being placed intro the production environment for testing.
Document impact ranging from total network failure to moderate inconvenience and include roll out time tables.
The roll out needs include travel times such drive to site B or fly cross country.
Of course the downside of this is that management may go out and hire someone who knows, or at least pretends to know, how to drop changes into place without whining about ignorance and making customers uncomfortable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547880</id>
	<title>You could simulate the net with Packet Tracer</title>
	<author>sconeu</author>
	<datestamp>1261657500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Granted, it's not really an ideal solution, but it may wind up being the only way to avoid using production equipment.</p></htmltext>
<tokenext>Granted , it 's not really an ideal solution , but it may wind up being the only way to avoid using production equipment .</tokentext>
<sentencetext>Granted, it's not really an ideal solution, but it may wind up being the only way to avoid using production equipment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551230</id>
	<title>Labs are not the whole answer</title>
	<author>axafg00b</author>
	<datestamp>1261761780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Labs, yeah, good times! The biggest problem is keeping the labs both operational and relevant. I just finished cleaning out my company's network lab as the switchgear was not L3-capable, out of production and out of our network, and none of the interfaces were faster than 100Mbps. None of it could be updated to a relevant OS level. It is mentioned earlier that if you are a large enough network, you designate a branch to serve as a guinea pig for planned changes. Also, if you have a branch close down, make sure you reclaim the equipment if it is new enough and use that for your 'lab' until the next refresh. Sadly, using older equipment only works if you never plan to use leading (bleeding?) edge features. However, my colleagues and I have found that using older equipment sometimes masks new and unknown interactions between the new services and older, perceived-stable, protocols.</p><p>Plan ahead meticulously - using paper and pen is not a sin as it is often faster than trying to model your system in software. Also, leverage your vendors heavily. They have the latest gear, and hopefully you will have service contracts, and they can assist you in planning out major changes.</p><p>Praying when a change goes in is good, too.</p></htmltext>
<tokenext>Labs , yeah , good times !
The biggest problem is keeping the labs both operational and relevant .
I just finished cleaning out my company 's network lab as the switchgear was not L3-capable , out of production and out of our network , and none of the interfaces were faster than 100Mbps .
None of it could be updated to a relevant OS level .
It is mentioned earlier that if you are a large enough network , you designate a branch to serve as a guinea pig for planned changes .
Also , if you have a branch close down , make sure you reclaim the equipment if it is new enough and use that for your 'lab ' until the next refresh .
Sadly , using older equipment only works if you never plan to use leading ( bleeding ?
) edge features .
However , my colleagues and I have found that using older equipment sometimes masks new and unknown interactions between the new services and older , perceived-stable , protocols.Plan ahead meticulously - using paper and pen is not a sin as it is often faster than trying to model your system in software .
Also , leverage your vendors heavily .
They have the latest gear , and hopefully you will have service contracts , and they can assist you in planning out major changes.Praying when a change goes in is good , too .</tokentext>
<sentencetext>Labs, yeah, good times!
The biggest problem is keeping the labs both operational and relevant.
I just finished cleaning out my company's network lab as the switchgear was not L3-capable, out of production and out of our network, and none of the interfaces were faster than 100Mbps.
None of it could be updated to a relevant OS level.
It is mentioned earlier that if you are a large enough network, you designate a branch to serve as a guinea pig for planned changes.
Also, if you have a branch close down, make sure you reclaim the equipment if it is new enough and use that for your 'lab' until the next refresh.
Sadly, using older equipment only works if you never plan to use leading (bleeding?
) edge features.
However, my colleagues and I have found that using older equipment sometimes masks new and unknown interactions between the new services and older, perceived-stable, protocols.Plan ahead meticulously - using paper and pen is not a sin as it is often faster than trying to model your system in software.
Also, leverage your vendors heavily.
They have the latest gear, and hopefully you will have service contracts, and they can assist you in planning out major changes.Praying when a change goes in is good, too.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548370</id>
	<title>Re:Document and test at night</title>
	<author>dbIII</author>
	<datestamp>1261663620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Sure it helps if you can test it beforehand, but sometimes your lab might not reflect what happens in real network when you roll something out.</p></div></blockquote><p>That means your experimental model is not good and needs to be refined.<br>You see - all those guys that did a six month course and call themselves "engineers" could have had some benefit of a real engineering education or the experience of working with real engineers.<br>Meanwhile I have idiots learning about routing or DHCP on production systems because they can't be bothered to go into another room and turn on power switches to run things on a development network.  It's very nice when developers work at improving their skillset, but the attitude of trying things to see if it works instead of RTFM is not compatible with anyone else using things at the same time.  We've been poisoned by the MSDOS mindset of the single user, poor documentation and the "just reboot and see if it works now" attitude.</p></div>
	</htmltext>
<tokenext>Sure it helps if you can test it beforehand , but sometimes your lab might not reflect what happens in real network when you roll something out.That means your experimental model is not good and needs to be refined.You see - all those guys that did a six month course and call themselves " engineers " could have had some benefit of a real engineering education or the experience of working with real engineers.Meanwhile I have idiots learning about routing or DHCP on production systems because they ca n't be bothered to go into another room and turn on power switches to run things on a development network .
It 's very nice when developers work at improving their skillset , but the attitude of trying things to see if it works instead of RTFM is not compatible with anyone else using things at the same time .
We 've been poisoned by the MSDOS mindset of the single user , poor documentation and the " just reboot and see if it works now " attitude .</tokentext>
<sentencetext>Sure it helps if you can test it beforehand, but sometimes your lab might not reflect what happens in real network when you roll something out.That means your experimental model is not good and needs to be refined.You see - all those guys that did a six month course and call themselves "engineers" could have had some benefit of a real engineering education or the experience of working with real engineers.Meanwhile I have idiots learning about routing or DHCP on production systems because they can't be bothered to go into another room and turn on power switches to run things on a development network.
It's very nice when developers work at improving their skillset, but the attitude of trying things to see if it works instead of RTFM is not compatible with anyone else using things at the same time.
We've been poisoned by the MSDOS mindset of the single user, poor documentation and the "just reboot and see if it works now" attitude.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548000</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</id>
	<title>The tag says it all</title>
	<author>Lord Byron II</author>
	<datestamp>1261657200000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>There are zero replies and the story is already tagged with "youreboned". That's the truth. If your higher ups won't front the money for proper test equipment and expect you to roll out production-ready equipment on the first go, then you really are boned. Of course, you can mitigate this by simple pen-and-paper analysis. What should each piece of equipment do? Are the products we've selected appropriate for the roles we're going to put them in? These sorts of questions can find a lot of bugs without any sort of testing. If you think, "what would I do if it was the 1980's?" then you'll be fine.</p></htmltext>
<tokenext>There are zero replies and the story is already tagged with " youreboned " .
That 's the truth .
If your higher ups wo n't front the money for proper test equipment and expect you to roll out production-ready equipment on the first go , then you really are boned .
Of course , you can mitigate this by simple pen-and-paper analysis .
What should each piece of equipment do ?
Are the products we 've selected appropriate for the roles we 're going to put them in ?
These sorts of questions can find a lot of bugs without any sort of testing .
If you think , " what would I do if it was the 1980 's ?
" then you 'll be fine .</tokentext>
<sentencetext>There are zero replies and the story is already tagged with "youreboned".
That's the truth.
If your higher ups won't front the money for proper test equipment and expect you to roll out production-ready equipment on the first go, then you really are boned.
Of course, you can mitigate this by simple pen-and-paper analysis.
What should each piece of equipment do?
Are the products we've selected appropriate for the roles we're going to put them in?
These sorts of questions can find a lot of bugs without any sort of testing.
If you think, "what would I do if it was the 1980's?
" then you'll be fine.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548348</id>
	<title>Don't forget SOX</title>
	<author>jackb\_guppy</author>
	<datestamp>1261663440000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>1) You should not be making any direct changes to the network with out correct design, test and sign off.</p><p>2) You should already have a redundant network structure, so "half" can be loss without any loss to network operations.  This way the change can be tested in parallel.</p><p>3) You should always report to SOX officer when a request outside correct operations and management is made.  It makes it their responsibility to solve the legal issues, for not following their written standards, before you began.</p></htmltext>
<tokenext>1 ) You should not be making any direct changes to the network with out correct design , test and sign off.2 ) You should already have a redundant network structure , so " half " can be loss without any loss to network operations .
This way the change can be tested in parallel.3 ) You should always report to SOX officer when a request outside correct operations and management is made .
It makes it their responsibility to solve the legal issues , for not following their written standards , before you began .</tokentext>
<sentencetext>1) You should not be making any direct changes to the network with out correct design, test and sign off.2) You should already have a redundant network structure, so "half" can be loss without any loss to network operations.
This way the change can be tested in parallel.3) You should always report to SOX officer when a request outside correct operations and management is made.
It makes it their responsibility to solve the legal issues, for not following their written standards, before you began.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</id>
	<title>Document and test at night</title>
	<author>jdigriz</author>
	<datestamp>1261657620000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext>Step 1)
Make a formal request for the test lab. Make it as detailed as possible. Explain the impact to business if various components fail. Make a plain-language  executive summary calling out risks.

step 2) Once the request is denied, make sure you have a paper trail of the rejection

step 3) If possible test network changes on the production equipment at 2am so that impact on users will be less

step 4) Once the inevitable failure occurs, haul out the paper trail and get the bean counter fired.

Repeat until test lab is approved.

Note, step 4 may get you fired instead. Business decisions are somewhat nondeterministic.</htmltext>
<tokenext>Step 1 ) Make a formal request for the test lab .
Make it as detailed as possible .
Explain the impact to business if various components fail .
Make a plain-language executive summary calling out risks .
step 2 ) Once the request is denied , make sure you have a paper trail of the rejection step 3 ) If possible test network changes on the production equipment at 2am so that impact on users will be less step 4 ) Once the inevitable failure occurs , haul out the paper trail and get the bean counter fired .
Repeat until test lab is approved .
Note , step 4 may get you fired instead .
Business decisions are somewhat nondeterministic .</tokentext>
<sentencetext>Step 1)
Make a formal request for the test lab.
Make it as detailed as possible.
Explain the impact to business if various components fail.
Make a plain-language  executive summary calling out risks.
step 2) Once the request is denied, make sure you have a paper trail of the rejection

step 3) If possible test network changes on the production equipment at 2am so that impact on users will be less

step 4) Once the inevitable failure occurs, haul out the paper trail and get the bean counter fired.
Repeat until test lab is approved.
Note, step 4 may get you fired instead.
Business decisions are somewhat nondeterministic.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549654</id>
	<title>Re:Pretty simple, really</title>
	<author>Anonymous</author>
	<datestamp>1261772340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Well said.  The same people wouldn't operate their car without AAA, OnStar and a fullsize spare tire think nothing of operating their datacenter without so much as a cold spare hard drive.  It's unfortunate.</htmltext>
<tokenext>Well said .
The same people would n't operate their car without AAA , OnStar and a fullsize spare tire think nothing of operating their datacenter without so much as a cold spare hard drive .
It 's unfortunate .</tokentext>
<sentencetext>Well said.
The same people wouldn't operate their car without AAA, OnStar and a fullsize spare tire think nothing of operating their datacenter without so much as a cold spare hard drive.
It's unfortunate.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548904</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547860</id>
	<title>Virtualization?</title>
	<author>bsDaemon</author>
	<datestamp>1261657320000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>4</modscore>
	<htmltext>It's perhaps not the best solution, as a lot of problems I've faced since I started getting more into networking stuff than software configuration and web server administration have been related to bad cables rather than bad IOS settings, but virtualization can help you create test situations on the cheep.  Specifically, GNS3 allows you to create test networks in a virtual environment, then import software images for your Cisco routers, switches, PIX firewalls, Juniper hardware, etc, all run on hypervisor technology.<br><br>You can also use QEMU to create virtual network nodes.  If you have enough RAM, then this can help at least get the logical issues worked out and the software configurations square.  Then you just need to do the real work<nobr> <wbr></nobr>:)  I'm still pretty new to networking myself, and I use it to make little test labs for myself when I need to do more than I can with the two 3600 and the 2600-series routers I got to take home for experimenting with.  I actually copied the IOS images off of them via TFTP and then can replicate them as many times as I need to, but I can claim I have whatever interfaces I need, plus it will (thankfully) simulate the ATM switch for me as well.</htmltext>
<tokenext>It 's perhaps not the best solution , as a lot of problems I 've faced since I started getting more into networking stuff than software configuration and web server administration have been related to bad cables rather than bad IOS settings , but virtualization can help you create test situations on the cheep .
Specifically , GNS3 allows you to create test networks in a virtual environment , then import software images for your Cisco routers , switches , PIX firewalls , Juniper hardware , etc , all run on hypervisor technology.You can also use QEMU to create virtual network nodes .
If you have enough RAM , then this can help at least get the logical issues worked out and the software configurations square .
Then you just need to do the real work : ) I 'm still pretty new to networking myself , and I use it to make little test labs for myself when I need to do more than I can with the two 3600 and the 2600-series routers I got to take home for experimenting with .
I actually copied the IOS images off of them via TFTP and then can replicate them as many times as I need to , but I can claim I have whatever interfaces I need , plus it will ( thankfully ) simulate the ATM switch for me as well .</tokentext>
<sentencetext>It's perhaps not the best solution, as a lot of problems I've faced since I started getting more into networking stuff than software configuration and web server administration have been related to bad cables rather than bad IOS settings, but virtualization can help you create test situations on the cheep.
Specifically, GNS3 allows you to create test networks in a virtual environment, then import software images for your Cisco routers, switches, PIX firewalls, Juniper hardware, etc, all run on hypervisor technology.You can also use QEMU to create virtual network nodes.
If you have enough RAM, then this can help at least get the logical issues worked out and the software configurations square.
Then you just need to do the real work :)  I'm still pretty new to networking myself, and I use it to make little test labs for myself when I need to do more than I can with the two 3600 and the 2600-series routers I got to take home for experimenting with.
I actually copied the IOS images off of them via TFTP and then can replicate them as many times as I need to, but I can claim I have whatever interfaces I need, plus it will (thankfully) simulate the ATM switch for me as well.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30550968</id>
	<title>The horrible, but necessary answer</title>
	<author>Anonymous</author>
	<datestamp>1261757880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Before testing, write up a detailed plan as to why you think this testing should be done on nonproduction equipment. Express your concern that it's EXTREMELY UNWISE to test on production equipment, but that this is the only alternative if you wish to deploy a final working system.Send email far and wide regarding your concerns. CC yourself at your own personal email address.</p><p>In short, cover your hiney. If bozo the manager wants to take the risk, you MUST be able to provide ample documented evidence that he/she/it was warned.</p></htmltext>
<tokenext>Before testing , write up a detailed plan as to why you think this testing should be done on nonproduction equipment .
Express your concern that it 's EXTREMELY UNWISE to test on production equipment , but that this is the only alternative if you wish to deploy a final working system.Send email far and wide regarding your concerns .
CC yourself at your own personal email address.In short , cover your hiney .
If bozo the manager wants to take the risk , you MUST be able to provide ample documented evidence that he/she/it was warned .</tokentext>
<sentencetext>Before testing, write up a detailed plan as to why you think this testing should be done on nonproduction equipment.
Express your concern that it's EXTREMELY UNWISE to test on production equipment, but that this is the only alternative if you wish to deploy a final working system.Send email far and wide regarding your concerns.
CC yourself at your own personal email address.In short, cover your hiney.
If bozo the manager wants to take the risk, you MUST be able to provide ample documented evidence that he/she/it was warned.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547988</id>
	<title>lots of little things</title>
	<author>wintermute000</author>
	<datestamp>1261658700000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Older Cisco equipment can function just as well as newer for 95\% of lab scenarios. You are very unlikely to be needing to use all the newer features.</p><p>Anything that can run IOS 12.3 and is newer than a decade old can do a lot more than you think. We do all our BGP testing on a stack of 2600s and 3600s and never an issue even though in production its 2800s, 3800s etc.<br>Granted there are features that you do need the newer kit esp when syntax changes (e.g. IP SLA commands, newer netflow commands, class map based QoS to name three off the top of my head) but none of the core routing and switching features/commands has changed much since the introduction of CEF - they all do ACLs, route maps, OSPF, BGP, EIGRP, vlans, spanning tree, rapid spanning tree, IPSEC vpns. I'm speaking from an enterprise POV not a service provider but I'd imagine if you are in a telco environment you wouldn't be lacking gear.</p><p>For many minor test scenarios, you can pick a test branch office and use the good old 'reload in XYZ' command to ensure that no matter how badly you stuff it up, everything will bounce and come back (just remember NOT TO COPY RUN START lol).</p><p>Then there's the sleight of hand methods:<br>- always ordering more for projects than you really need. Par for the course really esp as most project managers haven't a clue when it comes to the nuts and bolts of a big cisco order.<br>- pushing for EOL replacements as early as possible, intentionally conflate end of sale with end of life.<br>- getting stuff in for projects as early as possible, then you have a month or two to use it as test gear.<br>- remember that your lab need not mirror reality, scale down as much as possible. e.g. to simulate a pair of 4506 multilayer switch running in VRRP, use a pair of 3560s. Use your CCO login and flash away to your hearts content (I know its breaching licencing but for test scenarios, meh).</p></htmltext>
<tokenext>Older Cisco equipment can function just as well as newer for 95 \ % of lab scenarios .
You are very unlikely to be needing to use all the newer features.Anything that can run IOS 12.3 and is newer than a decade old can do a lot more than you think .
We do all our BGP testing on a stack of 2600s and 3600s and never an issue even though in production its 2800s , 3800s etc.Granted there are features that you do need the newer kit esp when syntax changes ( e.g .
IP SLA commands , newer netflow commands , class map based QoS to name three off the top of my head ) but none of the core routing and switching features/commands has changed much since the introduction of CEF - they all do ACLs , route maps , OSPF , BGP , EIGRP , vlans , spanning tree , rapid spanning tree , IPSEC vpns .
I 'm speaking from an enterprise POV not a service provider but I 'd imagine if you are in a telco environment you would n't be lacking gear.For many minor test scenarios , you can pick a test branch office and use the good old 'reload in XYZ ' command to ensure that no matter how badly you stuff it up , everything will bounce and come back ( just remember NOT TO COPY RUN START lol ) .Then there 's the sleight of hand methods : - always ordering more for projects than you really need .
Par for the course really esp as most project managers have n't a clue when it comes to the nuts and bolts of a big cisco order.- pushing for EOL replacements as early as possible , intentionally conflate end of sale with end of life.- getting stuff in for projects as early as possible , then you have a month or two to use it as test gear.- remember that your lab need not mirror reality , scale down as much as possible .
e.g. to simulate a pair of 4506 multilayer switch running in VRRP , use a pair of 3560s .
Use your CCO login and flash away to your hearts content ( I know its breaching licencing but for test scenarios , meh ) .</tokentext>
<sentencetext>Older Cisco equipment can function just as well as newer for 95\% of lab scenarios.
You are very unlikely to be needing to use all the newer features.Anything that can run IOS 12.3 and is newer than a decade old can do a lot more than you think.
We do all our BGP testing on a stack of 2600s and 3600s and never an issue even though in production its 2800s, 3800s etc.Granted there are features that you do need the newer kit esp when syntax changes (e.g.
IP SLA commands, newer netflow commands, class map based QoS to name three off the top of my head) but none of the core routing and switching features/commands has changed much since the introduction of CEF - they all do ACLs, route maps, OSPF, BGP, EIGRP, vlans, spanning tree, rapid spanning tree, IPSEC vpns.
I'm speaking from an enterprise POV not a service provider but I'd imagine if you are in a telco environment you wouldn't be lacking gear.For many minor test scenarios, you can pick a test branch office and use the good old 'reload in XYZ' command to ensure that no matter how badly you stuff it up, everything will bounce and come back (just remember NOT TO COPY RUN START lol).Then there's the sleight of hand methods:- always ordering more for projects than you really need.
Par for the course really esp as most project managers haven't a clue when it comes to the nuts and bolts of a big cisco order.- pushing for EOL replacements as early as possible, intentionally conflate end of sale with end of life.- getting stuff in for projects as early as possible, then you have a month or two to use it as test gear.- remember that your lab need not mirror reality, scale down as much as possible.
e.g. to simulate a pair of 4506 multilayer switch running in VRRP, use a pair of 3560s.
Use your CCO login and flash away to your hearts content (I know its breaching licencing but for test scenarios, meh).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549846</id>
	<title>Re:Pretty simple, really</title>
	<author>lukas84</author>
	<datestamp>1261733520000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><p>Everyone has a test environment. But not everyone has a production environment.</p></htmltext>
<tokenext>Everyone has a test environment .
But not everyone has a production environment .</tokentext>
<sentencetext>Everyone has a test environment.
But not everyone has a production environment.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548414</id>
	<title>Re:Tools</title>
	<author>Anonymous</author>
	<datestamp>1261664340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Those are great recommendations, thanks!</p></htmltext>
<tokenext>Those are great recommendations , thanks !</tokentext>
<sentencetext>Those are great recommendations, thanks!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547976</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548226</id>
	<title>Don't waste the next crisis/flap</title>
	<author>Anonymous</author>
	<datestamp>1261661520000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p> When it happens, point out (on paper!) to yr mgmt chain how it cd have been prevented with a decent test configuration in place.</p></htmltext>
<tokenext>When it happens , point out ( on paper !
) to yr mgmt chain how it cd have been prevented with a decent test configuration in place .</tokentext>
<sentencetext> When it happens, point out (on paper!
) to yr mgmt chain how it cd have been prevented with a decent test configuration in place.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548104</id>
	<title>The power of logic compels me!</title>
	<author>Anonymous</author>
	<datestamp>1261659900000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>You do not mention that this has ever made shit hit a fan. I conclude that so far this has not occured.</p><p>Consequently, you have proved that you are able to work without expensive test equipment by a combination and motivation and elbow grease. Congratulations!</p><p>Now, what is the logic for someone with a finite pool of money to provide equipment for someone who obviously does not NEED it? Yes, None At All!</p><p>You can therefore:<br>1) Wait until shit hits a fan and say "well, that's what happens when we don't have test equipment". You will then get test equipment OR get fired.<br>2) Make the shit hit the fan yourself. This is quite difficult to do inconspicuously, so you'll probably get fired and a shit reference.<br>3) Look around for jobs as well paid as yours but with test equipment.<br>4) Someone mentioned asking vendors for test equipment - maybe that might work? Note: sales reps have a quota of favours they can call in, so it helps if you have some steady business with them.</p></htmltext>
<tokenext>You do not mention that this has ever made shit hit a fan .
I conclude that so far this has not occured.Consequently , you have proved that you are able to work without expensive test equipment by a combination and motivation and elbow grease .
Congratulations ! Now , what is the logic for someone with a finite pool of money to provide equipment for someone who obviously does not NEED it ?
Yes , None At All ! You can therefore : 1 ) Wait until shit hits a fan and say " well , that 's what happens when we do n't have test equipment " .
You will then get test equipment OR get fired.2 ) Make the shit hit the fan yourself .
This is quite difficult to do inconspicuously , so you 'll probably get fired and a shit reference.3 ) Look around for jobs as well paid as yours but with test equipment.4 ) Someone mentioned asking vendors for test equipment - maybe that might work ?
Note : sales reps have a quota of favours they can call in , so it helps if you have some steady business with them .</tokentext>
<sentencetext>You do not mention that this has ever made shit hit a fan.
I conclude that so far this has not occured.Consequently, you have proved that you are able to work without expensive test equipment by a combination and motivation and elbow grease.
Congratulations!Now, what is the logic for someone with a finite pool of money to provide equipment for someone who obviously does not NEED it?
Yes, None At All!You can therefore:1) Wait until shit hits a fan and say "well, that's what happens when we don't have test equipment".
You will then get test equipment OR get fired.2) Make the shit hit the fan yourself.
This is quite difficult to do inconspicuously, so you'll probably get fired and a shit reference.3) Look around for jobs as well paid as yours but with test equipment.4) Someone mentioned asking vendors for test equipment - maybe that might work?
Note: sales reps have a quota of favours they can call in, so it helps if you have some steady business with them.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30580858</id>
	<title>Risk is the factor you are wanting to reduce</title>
	<author>Private Baldrick</author>
	<datestamp>1262091060000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>What I'd suggest is something quiet alien to the tekhead. Get management on your side.
Explain the issues talk about the problems. Give them easy to read bullet points.

Management will then ask you "Well what do you suggest?"

Well you know a lab that effectively mirrors the live environment is about as likely as rocking horse poo but ask about it anyway. If you have concerns they won't fork out the money for it then it's most likely a case that they won't but ask for it and make sure they understand and you discuss it...

Assuming you didn't get a lab then talk about the change. Talk them over the mitigation you want to plan in, talk about the rollback, get them on board. Then hit them with a compromise. You know the network better than anyone; work out what equipment you do need to replicate the vast majority of the network.

If 90\% of your network is based upon say 3 standard models of switches/routers ask for a lab of them. Discuss that you can reduce the risk.

Risk is factor you are looking at trying to reduce. You should be able to speak to you management saying.

Option 1 cost $50000 99\% of network tested
Option 2 cost $10000 95\% of the network tested
Option 3 cost $5000 90\% of the network tested

The important thing is by getting them in on the dialog and the issue you face the risk assessment and responsibility is being shared between you and management. If things still go south you have some defence against people yelling at you, in fact management will understand the lengths you have gone to to reduce the risk &amp; they will understand that you cannot promise 0\% risk on the budget they want and they will have agreed to this...</htmltext>
<tokenext>What I 'd suggest is something quiet alien to the tekhead .
Get management on your side .
Explain the issues talk about the problems .
Give them easy to read bullet points .
Management will then ask you " Well what do you suggest ?
" Well you know a lab that effectively mirrors the live environment is about as likely as rocking horse poo but ask about it anyway .
If you have concerns they wo n't fork out the money for it then it 's most likely a case that they wo n't but ask for it and make sure they understand and you discuss it.. . Assuming you did n't get a lab then talk about the change .
Talk them over the mitigation you want to plan in , talk about the rollback , get them on board .
Then hit them with a compromise .
You know the network better than anyone ; work out what equipment you do need to replicate the vast majority of the network .
If 90 \ % of your network is based upon say 3 standard models of switches/routers ask for a lab of them .
Discuss that you can reduce the risk .
Risk is factor you are looking at trying to reduce .
You should be able to speak to you management saying .
Option 1 cost $ 50000 99 \ % of network tested Option 2 cost $ 10000 95 \ % of the network tested Option 3 cost $ 5000 90 \ % of the network tested The important thing is by getting them in on the dialog and the issue you face the risk assessment and responsibility is being shared between you and management .
If things still go south you have some defence against people yelling at you , in fact management will understand the lengths you have gone to to reduce the risk &amp; they will understand that you can not promise 0 \ % risk on the budget they want and they will have agreed to this.. .</tokentext>
<sentencetext>What I'd suggest is something quiet alien to the tekhead.
Get management on your side.
Explain the issues talk about the problems.
Give them easy to read bullet points.
Management will then ask you "Well what do you suggest?
"

Well you know a lab that effectively mirrors the live environment is about as likely as rocking horse poo but ask about it anyway.
If you have concerns they won't fork out the money for it then it's most likely a case that they won't but ask for it and make sure they understand and you discuss it...

Assuming you didn't get a lab then talk about the change.
Talk them over the mitigation you want to plan in, talk about the rollback, get them on board.
Then hit them with a compromise.
You know the network better than anyone; work out what equipment you do need to replicate the vast majority of the network.
If 90\% of your network is based upon say 3 standard models of switches/routers ask for a lab of them.
Discuss that you can reduce the risk.
Risk is factor you are looking at trying to reduce.
You should be able to speak to you management saying.
Option 1 cost $50000 99\% of network tested
Option 2 cost $10000 95\% of the network tested
Option 3 cost $5000 90\% of the network tested

The important thing is by getting them in on the dialog and the issue you face the risk assessment and responsibility is being shared between you and management.
If things still go south you have some defence against people yelling at you, in fact management will understand the lengths you have gone to to reduce the risk &amp; they will understand that you cannot promise 0\% risk on the budget they want and they will have agreed to this...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547858</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548554</id>
	<title>Re:The tag says it all</title>
	<author>eggoeater</author>
	<datestamp>1261667160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext>I'm a call-center telephony engineer.  Kinda the same thing as network engineer in that you're routing calls instead of packets.<br>
Back around '01, I was working for First Union (which later became Wachovia).
They had this massive corporate push for anyone and everyone in IT to roll out a standardized <a href="http://en.wikipedia.org/wiki/Configuration\_management" title="wikipedia.org">Software Configuration Management</a> [wikipedia.org],
and of course we were included.  The big problem was the lab.  The corporate standard was to test changes in a lab environment and then move to production (duh).<br>
For a telephony environment, we had a pretty good lab that could duplicate most of our production scenarios, but not all.
Another problem was there were a LOT of people with their fingers in the lab since so many groups were involved: eg. The IVR team is in there because you have to have IVRs in the system.  Same with
call routing, call recording, desktop software, Q&amp;A, etc.etc.<br>
So the lab was in a constant state of flux with multiple products, multiple teams, and different software cycles and endless testing always occurring.
We made it work by testing the stuff we weren't sure about in the lab, only doing changes in prod after hours, and having really good testing and back-out plans.
<br>
So when the corporate overlords started telling use we couldn't make any changes to production without running everything through the lab first, we basically laughed and told
them we'd need around 500 million for the lab and dedicated resources to run it.  I ended up telling them that to duplicate the production environment, we'd need another bank
as our "test bank", and we could test changes on the test bank and then put them in the production bank.<br> <br>
As with so many things in that IT department, it went from being a priority to fading away when something else became a priority.</htmltext>
<tokenext>I 'm a call-center telephony engineer .
Kinda the same thing as network engineer in that you 're routing calls instead of packets .
Back around '01 , I was working for First Union ( which later became Wachovia ) .
They had this massive corporate push for anyone and everyone in IT to roll out a standardized Software Configuration Management [ wikipedia.org ] , and of course we were included .
The big problem was the lab .
The corporate standard was to test changes in a lab environment and then move to production ( duh ) .
For a telephony environment , we had a pretty good lab that could duplicate most of our production scenarios , but not all .
Another problem was there were a LOT of people with their fingers in the lab since so many groups were involved : eg .
The IVR team is in there because you have to have IVRs in the system .
Same with call routing , call recording , desktop software , Q&amp;A , etc.etc .
So the lab was in a constant state of flux with multiple products , multiple teams , and different software cycles and endless testing always occurring .
We made it work by testing the stuff we were n't sure about in the lab , only doing changes in prod after hours , and having really good testing and back-out plans .
So when the corporate overlords started telling use we could n't make any changes to production without running everything through the lab first , we basically laughed and told them we 'd need around 500 million for the lab and dedicated resources to run it .
I ended up telling them that to duplicate the production environment , we 'd need another bank as our " test bank " , and we could test changes on the test bank and then put them in the production bank .
As with so many things in that IT department , it went from being a priority to fading away when something else became a priority .</tokentext>
<sentencetext>I'm a call-center telephony engineer.
Kinda the same thing as network engineer in that you're routing calls instead of packets.
Back around '01, I was working for First Union (which later became Wachovia).
They had this massive corporate push for anyone and everyone in IT to roll out a standardized Software Configuration Management [wikipedia.org],
and of course we were included.
The big problem was the lab.
The corporate standard was to test changes in a lab environment and then move to production (duh).
For a telephony environment, we had a pretty good lab that could duplicate most of our production scenarios, but not all.
Another problem was there were a LOT of people with their fingers in the lab since so many groups were involved: eg.
The IVR team is in there because you have to have IVRs in the system.
Same with
call routing, call recording, desktop software, Q&amp;A, etc.etc.
So the lab was in a constant state of flux with multiple products, multiple teams, and different software cycles and endless testing always occurring.
We made it work by testing the stuff we weren't sure about in the lab, only doing changes in prod after hours, and having really good testing and back-out plans.
So when the corporate overlords started telling use we couldn't make any changes to production without running everything through the lab first, we basically laughed and told
them we'd need around 500 million for the lab and dedicated resources to run it.
I ended up telling them that to duplicate the production environment, we'd need another bank
as our "test bank", and we could test changes on the test bank and then put them in the production bank.
As with so many things in that IT department, it went from being a priority to fading away when something else became a priority.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549822</id>
	<title>Changes during bussiness hours</title>
	<author>Anonymous</author>
	<datestamp>1261733160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>We actually try to put non-downtime incurring changes though during business hours, this way any unexpected issues will come up immediately and we can react. Rather than  This is in a seizable high end production environment.</p></htmltext>
<tokenext>We actually try to put non-downtime incurring changes though during business hours , this way any unexpected issues will come up immediately and we can react .
Rather than This is in a seizable high end production environment .</tokentext>
<sentencetext>We actually try to put non-downtime incurring changes though during business hours, this way any unexpected issues will come up immediately and we can react.
Rather than  This is in a seizable high end production environment.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551026</id>
	<title>Re:The tag says it all</title>
	<author>Anonymous</author>
	<datestamp>1261759020000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Cisco supports rollback too:<br>http://www.cisco.com/en/US/docs/ios\_xr\_sw/iosxr\_r3.3/getting\_started/installation/guide/gs33init.html#wp1159138</p></htmltext>
<tokenext>Cisco supports rollback too : http : //www.cisco.com/en/US/docs/ios \ _xr \ _sw/iosxr \ _r3.3/getting \ _started/installation/guide/gs33init.html # wp1159138</tokentext>
<sentencetext>Cisco supports rollback too:http://www.cisco.com/en/US/docs/ios\_xr\_sw/iosxr\_r3.3/getting\_started/installation/guide/gs33init.html#wp1159138</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548472</id>
	<title>Re:Document and test at night</title>
	<author>Anonymous</author>
	<datestamp>1261665300000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p><div class="quote"><p>Note, step 4 may get you fired instead. Business decisions are somewhat nondeterministic.</p></div><p>And that's what happened to me.</p><p>I was forced into making changes in the production environment, and caused an outage that affected 2 people.  Once I realized what happened, I quickly fixed it; however due to internal politics I was terminated the next day.</p><p>Initially I was in shock.  10 years, 2 months employed in a single company.  Gone.  I have a stay-at-home wife and 3 kids; which made things look even bleaker.</p><p>In hindsight, it may be one of the better things to happen to me.  I had spoken with a recruiter a few days before hand to start looking for work.  When this happened, I was able to dedicate myself full time for job-searching.  I was also off for hunting season, and able to do many things with my family that I normally wouldn't be able to do.  The environment where I was was just awful. Several former co-workers have left since my special day.  The CTO is a psychopath.  He has 2 sayings he likes to use - the first is 'to do the job right the 1st time'.  The second is a Mario Andretti quote of 'If you don't feel like you are out of control, then you aren't going fast enough'.  These sayings are mutually exclusive, but logic doesn't apply.</p><p>I start a new position on Jan 5th (but it is only a 6 month contract position).  It is a bit more money, and I have about 1/2 the commute.  It is also a much better work environment.</p><p>Things I learned:</p><p>- Stockholm syndrome is apparently real.  I didn't want to leave because 'it's not that bad'.  It was bad.  Worse.<br>- I hate job hunting.<br>- Employment law in Ontario, Canada is not what I thought it was.  Pretty much everything I though I knew was wrong.<br>- The economy here in Ontario is poor, but improving (but vastly better than the US).<br>- Legal advise in Ontario is tax deductible (at least in reference to employment issues).<br>- A certain CTO is a complete and total prick.</p><p>(ha - my captcha word is 'inaction')</p></div>
	</htmltext>
<tokenext>Note , step 4 may get you fired instead .
Business decisions are somewhat nondeterministic.And that 's what happened to me.I was forced into making changes in the production environment , and caused an outage that affected 2 people .
Once I realized what happened , I quickly fixed it ; however due to internal politics I was terminated the next day.Initially I was in shock .
10 years , 2 months employed in a single company .
Gone. I have a stay-at-home wife and 3 kids ; which made things look even bleaker.In hindsight , it may be one of the better things to happen to me .
I had spoken with a recruiter a few days before hand to start looking for work .
When this happened , I was able to dedicate myself full time for job-searching .
I was also off for hunting season , and able to do many things with my family that I normally would n't be able to do .
The environment where I was was just awful .
Several former co-workers have left since my special day .
The CTO is a psychopath .
He has 2 sayings he likes to use - the first is 'to do the job right the 1st time' .
The second is a Mario Andretti quote of 'If you do n't feel like you are out of control , then you are n't going fast enough' .
These sayings are mutually exclusive , but logic does n't apply.I start a new position on Jan 5th ( but it is only a 6 month contract position ) .
It is a bit more money , and I have about 1/2 the commute .
It is also a much better work environment.Things I learned : - Stockholm syndrome is apparently real .
I did n't want to leave because 'it 's not that bad' .
It was bad .
Worse.- I hate job hunting.- Employment law in Ontario , Canada is not what I thought it was .
Pretty much everything I though I knew was wrong.- The economy here in Ontario is poor , but improving ( but vastly better than the US ) .- Legal advise in Ontario is tax deductible ( at least in reference to employment issues ) .- A certain CTO is a complete and total prick .
( ha - my captcha word is 'inaction ' )</tokentext>
<sentencetext>Note, step 4 may get you fired instead.
Business decisions are somewhat nondeterministic.And that's what happened to me.I was forced into making changes in the production environment, and caused an outage that affected 2 people.
Once I realized what happened, I quickly fixed it; however due to internal politics I was terminated the next day.Initially I was in shock.
10 years, 2 months employed in a single company.
Gone.  I have a stay-at-home wife and 3 kids; which made things look even bleaker.In hindsight, it may be one of the better things to happen to me.
I had spoken with a recruiter a few days before hand to start looking for work.
When this happened, I was able to dedicate myself full time for job-searching.
I was also off for hunting season, and able to do many things with my family that I normally wouldn't be able to do.
The environment where I was was just awful.
Several former co-workers have left since my special day.
The CTO is a psychopath.
He has 2 sayings he likes to use - the first is 'to do the job right the 1st time'.
The second is a Mario Andretti quote of 'If you don't feel like you are out of control, then you aren't going fast enough'.
These sayings are mutually exclusive, but logic doesn't apply.I start a new position on Jan 5th (but it is only a 6 month contract position).
It is a bit more money, and I have about 1/2 the commute.
It is also a much better work environment.Things I learned:- Stockholm syndrome is apparently real.
I didn't want to leave because 'it's not that bad'.
It was bad.
Worse.- I hate job hunting.- Employment law in Ontario, Canada is not what I thought it was.
Pretty much everything I though I knew was wrong.- The economy here in Ontario is poor, but improving (but vastly better than the US).- Legal advise in Ontario is tax deductible (at least in reference to employment issues).- A certain CTO is a complete and total prick.
(ha - my captcha word is 'inaction')
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549760</id>
	<title>Try Junipers</title>
	<author>Anonymous</author>
	<datestamp>1261732140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Juniper routers have much more powerful management interface than Cisco.  They have built in configuration versioning, atomic changesets, allow easy rollback and can schedule commits. Also there is programmatic configuration API. If you have no test lab, Junipers can help you a lot.</p></htmltext>
<tokenext>Juniper routers have much more powerful management interface than Cisco .
They have built in configuration versioning , atomic changesets , allow easy rollback and can schedule commits .
Also there is programmatic configuration API .
If you have no test lab , Junipers can help you a lot .</tokentext>
<sentencetext>Juniper routers have much more powerful management interface than Cisco.
They have built in configuration versioning, atomic changesets, allow easy rollback and can schedule commits.
Also there is programmatic configuration API.
If you have no test lab, Junipers can help you a lot.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548356</id>
	<title>its the time to</title>
	<author>GooseYArd</author>
	<datestamp>1261663500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>polish your resume.</p></htmltext>
<tokenext>polish your resume .</tokentext>
<sentencetext>polish your resume.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549266</id>
	<title>Hope you're good and/or have a good relationship.</title>
	<author>Anonymous</author>
	<datestamp>1261677960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>I work in a small IT house that provides network support for quite a few customers that are not large enough to have their own IT people.</p><p>We're very Windows centric (yeah, I know, boo) and have no budget for any test equipment/training, yet am expected to be up to date on changes in Windows.To make matters worse, I'm not even supposed to have the time to test things out on our internal network and the pay is low enough that I can't afford to purchase equipment to test at home on my own time.</p><p>So, what works (kinda) for me has been to keep an eye out for equipment that has been abandoned by our sales team, (usually through extensive hardware problems that causes a customer to decide that it's not reliable enough for their network), and/or take equipment off of the sales shelf for testing. For the software/knowledge side, I will quite belligerently tell my boss to go away when I'm testing something that needs to get tested. This requires that you have a certain amount of clout and/or your boss is afraid of you quitting enough to let you get away with it.</p><p>On the customer/end user side, develop some sort of personal relationship with them, whether that be going out for drinks with them periodically, knowing what they do for fun and/or have them know what you do for fun (no, gaming doesn't cut it). Be up front with them when something does mess up (literally saying that you didn't realize that what you were doing might have that problem).</p><p>Never, ever blame someone else unless you're sure it's their fault, take the blame yourself-this'll save your ass when it really isn't your fault and someone tries to pin it on you.</p><p>---<br>Having said all of that, what you (and I) should really be doing is looking for a new job.</p></htmltext>
<tokenext>I work in a small IT house that provides network support for quite a few customers that are not large enough to have their own IT people.We 're very Windows centric ( yeah , I know , boo ) and have no budget for any test equipment/training , yet am expected to be up to date on changes in Windows.To make matters worse , I 'm not even supposed to have the time to test things out on our internal network and the pay is low enough that I ca n't afford to purchase equipment to test at home on my own time.So , what works ( kinda ) for me has been to keep an eye out for equipment that has been abandoned by our sales team , ( usually through extensive hardware problems that causes a customer to decide that it 's not reliable enough for their network ) , and/or take equipment off of the sales shelf for testing .
For the software/knowledge side , I will quite belligerently tell my boss to go away when I 'm testing something that needs to get tested .
This requires that you have a certain amount of clout and/or your boss is afraid of you quitting enough to let you get away with it.On the customer/end user side , develop some sort of personal relationship with them , whether that be going out for drinks with them periodically , knowing what they do for fun and/or have them know what you do for fun ( no , gaming does n't cut it ) .
Be up front with them when something does mess up ( literally saying that you did n't realize that what you were doing might have that problem ) .Never , ever blame someone else unless you 're sure it 's their fault , take the blame yourself-this 'll save your ass when it really is n't your fault and someone tries to pin it on you.---Having said all of that , what you ( and I ) should really be doing is looking for a new job .</tokentext>
<sentencetext>I work in a small IT house that provides network support for quite a few customers that are not large enough to have their own IT people.We're very Windows centric (yeah, I know, boo) and have no budget for any test equipment/training, yet am expected to be up to date on changes in Windows.To make matters worse, I'm not even supposed to have the time to test things out on our internal network and the pay is low enough that I can't afford to purchase equipment to test at home on my own time.So, what works (kinda) for me has been to keep an eye out for equipment that has been abandoned by our sales team, (usually through extensive hardware problems that causes a customer to decide that it's not reliable enough for their network), and/or take equipment off of the sales shelf for testing.
For the software/knowledge side, I will quite belligerently tell my boss to go away when I'm testing something that needs to get tested.
This requires that you have a certain amount of clout and/or your boss is afraid of you quitting enough to let you get away with it.On the customer/end user side, develop some sort of personal relationship with them, whether that be going out for drinks with them periodically, knowing what they do for fun and/or have them know what you do for fun (no, gaming doesn't cut it).
Be up front with them when something does mess up (literally saying that you didn't realize that what you were doing might have that problem).Never, ever blame someone else unless you're sure it's their fault, take the blame yourself-this'll save your ass when it really isn't your fault and someone tries to pin it on you.---Having said all of that, what you (and I) should really be doing is looking for a new job.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30564630</id>
	<title>cheat, lie and steal!</title>
	<author>itzdandy</author>
	<datestamp>1261944540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>seriously, buy a new router to replace a 'broken' one from a location and then somehow fix the broken one for your lab/office.</p><p>The truth is that sometimes you not only lack the equipment for lab testing, but also the real world usage scenario.  I am often stuck in a situation where I must backup a config and then experiment with production equipment and so am forced to do this outside of business hours.  I usually get a chance to do some functional testing offline but cant really put new systems through there paces very well in a lab.</p><p>The real key to success here?  know what you are doing.  You may have to work in less that ideal circumstances but you must be knowledgeable enough to fix a mistake in a reasonable amount of time.</p><p>Also consider getting your hands on a rig to do some virtualization. You can virtualize routers and server with something like Xenserver, vmware, or virtualbox.  I have done an entire mock deployment of a cisco firewall + windows server 2008 r2 system for remote client access(Windows) and site-to-site vpns(cisco) on a single Xenserver because I can virtualize the cisco router (its slow), windows servers, and even create seperate networks to simulate seperate switches, sites, network segments etc.  Q6600+8GB can be had for less than a grand at dell in whitebox.</p></htmltext>
<tokenext>seriously , buy a new router to replace a 'broken ' one from a location and then somehow fix the broken one for your lab/office.The truth is that sometimes you not only lack the equipment for lab testing , but also the real world usage scenario .
I am often stuck in a situation where I must backup a config and then experiment with production equipment and so am forced to do this outside of business hours .
I usually get a chance to do some functional testing offline but cant really put new systems through there paces very well in a lab.The real key to success here ?
know what you are doing .
You may have to work in less that ideal circumstances but you must be knowledgeable enough to fix a mistake in a reasonable amount of time.Also consider getting your hands on a rig to do some virtualization .
You can virtualize routers and server with something like Xenserver , vmware , or virtualbox .
I have done an entire mock deployment of a cisco firewall + windows server 2008 r2 system for remote client access ( Windows ) and site-to-site vpns ( cisco ) on a single Xenserver because I can virtualize the cisco router ( its slow ) , windows servers , and even create seperate networks to simulate seperate switches , sites , network segments etc .
Q6600 + 8GB can be had for less than a grand at dell in whitebox .</tokentext>
<sentencetext>seriously, buy a new router to replace a 'broken' one from a location and then somehow fix the broken one for your lab/office.The truth is that sometimes you not only lack the equipment for lab testing, but also the real world usage scenario.
I am often stuck in a situation where I must backup a config and then experiment with production equipment and so am forced to do this outside of business hours.
I usually get a chance to do some functional testing offline but cant really put new systems through there paces very well in a lab.The real key to success here?
know what you are doing.
You may have to work in less that ideal circumstances but you must be knowledgeable enough to fix a mistake in a reasonable amount of time.Also consider getting your hands on a rig to do some virtualization.
You can virtualize routers and server with something like Xenserver, vmware, or virtualbox.
I have done an entire mock deployment of a cisco firewall + windows server 2008 r2 system for remote client access(Windows) and site-to-site vpns(cisco) on a single Xenserver because I can virtualize the cisco router (its slow), windows servers, and even create seperate networks to simulate seperate switches, sites, network segments etc.
Q6600+8GB can be had for less than a grand at dell in whitebox.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549652</id>
	<title>Re:Download vyatta</title>
	<author>itwerx</author>
	<datestamp>1261772340000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>Tired of the VI vs EMACS war?
Try the new Vyatta vs pfSense conflict instead!<nobr> <wbr></nobr>:)

(pfSense is great...)</htmltext>
<tokenext>Tired of the VI vs EMACS war ?
Try the new Vyatta vs pfSense conflict instead !
: ) ( pfSense is great... )</tokentext>
<sentencetext>Tired of the VI vs EMACS war?
Try the new Vyatta vs pfSense conflict instead!
:)

(pfSense is great...)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547964</id>
	<title>Re:Virtualization?</title>
	<author>value\_added</author>
	<datestamp>1261658460000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext><p><i>Specifically, GNS3 allows you to create test networks in a virtual environment, then import software images for your Cisco routers, switches, PIX firewalls, Juniper hardware, etc, all run on hypervisor technology.</i></p><p>For anyone unfamiliar with GNS3, a <a href="http://www.gns3.net/" title="gns3.net">link to the website</a> [gns3.net]. There are versions available for Windows, Linux, and OS X.  FreeBSD already has it in ports.</p><p>As a side note, I'd add that maintaining a home lab (to the extent practicable and useful) is one way to side-step limitations of what your employer provides.  Consider it a combination of "Ongoing Professional Education" and "Proactive Job Security Measures" (i.e., "I better test this shit to save my ass tomorrow").</p></htmltext>
<tokenext>Specifically , GNS3 allows you to create test networks in a virtual environment , then import software images for your Cisco routers , switches , PIX firewalls , Juniper hardware , etc , all run on hypervisor technology.For anyone unfamiliar with GNS3 , a link to the website [ gns3.net ] .
There are versions available for Windows , Linux , and OS X. FreeBSD already has it in ports.As a side note , I 'd add that maintaining a home lab ( to the extent practicable and useful ) is one way to side-step limitations of what your employer provides .
Consider it a combination of " Ongoing Professional Education " and " Proactive Job Security Measures " ( i.e. , " I better test this shit to save my ass tomorrow " ) .</tokentext>
<sentencetext>Specifically, GNS3 allows you to create test networks in a virtual environment, then import software images for your Cisco routers, switches, PIX firewalls, Juniper hardware, etc, all run on hypervisor technology.For anyone unfamiliar with GNS3, a link to the website [gns3.net].
There are versions available for Windows, Linux, and OS X.  FreeBSD already has it in ports.As a side note, I'd add that maintaining a home lab (to the extent practicable and useful) is one way to side-step limitations of what your employer provides.
Consider it a combination of "Ongoing Professional Education" and "Proactive Job Security Measures" (i.e., "I better test this shit to save my ass tomorrow").</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547860</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548140</id>
	<title>In case it explodes</title>
	<author>Ximok</author>
	<datestamp>1261660620000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>reload in 5</p><p>I'm dead serious.  If you are on production stuff and you screw it up remotely, you can at least tell it to reload and pull it's old config.  You have some downtime, but it's better than the downtime you'd experience if you had to drive out there.</p></htmltext>
<tokenext>reload in 5I 'm dead serious .
If you are on production stuff and you screw it up remotely , you can at least tell it to reload and pull it 's old config .
You have some downtime , but it 's better than the downtime you 'd experience if you had to drive out there .</tokentext>
<sentencetext>reload in 5I'm dead serious.
If you are on production stuff and you screw it up remotely, you can at least tell it to reload and pull it's old config.
You have some downtime, but it's better than the downtime you'd experience if you had to drive out there.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547986</id>
	<title>Re:Document and test at night</title>
	<author>nametaken</author>
	<datestamp>1261658700000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>There's a potential hitch or two in your plan.</p><p>If it goes smoothly anyway, you might look like a whiner that didn't need the expensive toys to keep on the shelf.  They feel vindicated.  If it goes poorly they'll assume you didn't really try because you wanted to prove yourself right.</p></htmltext>
<tokenext>There 's a potential hitch or two in your plan.If it goes smoothly anyway , you might look like a whiner that did n't need the expensive toys to keep on the shelf .
They feel vindicated .
If it goes poorly they 'll assume you did n't really try because you wanted to prove yourself right .</tokentext>
<sentencetext>There's a potential hitch or two in your plan.If it goes smoothly anyway, you might look like a whiner that didn't need the expensive toys to keep on the shelf.
They feel vindicated.
If it goes poorly they'll assume you didn't really try because you wanted to prove yourself right.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548066</id>
	<title>Out of hours changes, and change managment</title>
	<author>anti-NAT</author>
	<datestamp>1261659480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>For any sort of medium to large network, you can't fully simulate it. That means you're always going to be making "untested" environment. So, you make very few changes rather than lots, you make sure after each change they've had the desired effect, and you have backout plans.</p></htmltext>
<tokenext>For any sort of medium to large network , you ca n't fully simulate it .
That means you 're always going to be making " untested " environment .
So , you make very few changes rather than lots , you make sure after each change they 've had the desired effect , and you have backout plans .</tokentext>
<sentencetext>For any sort of medium to large network, you can't fully simulate it.
That means you're always going to be making "untested" environment.
So, you make very few changes rather than lots, you make sure after each change they've had the desired effect, and you have backout plans.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30550942</id>
	<title>Whose Your Daddy?</title>
	<author>duanes1967</author>
	<datestamp>1261757400000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I have worked for a few companies that had limited labs, but none that had a comprehensive lab.  They would operate in staged upgrades and used emulators as a sanity check, plus a peer review by at least two other engineers.  Make sure that there is a management VLan in operation and just shift vc's as needed.  A wholesale re-engineering is just asking for it.

The key to the whole thing is, ensure you have remote (dialup) access to the routers in question, never save the changes until you are happy, and make sure you keep a good copy on flash in the router.

It comes down to your awesome Ninja router skills.  This is where a $100K network guy makes his money versus a $35K graduate. EXPERIENCE.</htmltext>
<tokenext>I have worked for a few companies that had limited labs , but none that had a comprehensive lab .
They would operate in staged upgrades and used emulators as a sanity check , plus a peer review by at least two other engineers .
Make sure that there is a management VLan in operation and just shift vc 's as needed .
A wholesale re-engineering is just asking for it .
The key to the whole thing is , ensure you have remote ( dialup ) access to the routers in question , never save the changes until you are happy , and make sure you keep a good copy on flash in the router .
It comes down to your awesome Ninja router skills .
This is where a $ 100K network guy makes his money versus a $ 35K graduate .
EXPERIENCE .</tokentext>
<sentencetext>I have worked for a few companies that had limited labs, but none that had a comprehensive lab.
They would operate in staged upgrades and used emulators as a sanity check, plus a peer review by at least two other engineers.
Make sure that there is a management VLan in operation and just shift vc's as needed.
A wholesale re-engineering is just asking for it.
The key to the whole thing is, ensure you have remote (dialup) access to the routers in question, never save the changes until you are happy, and make sure you keep a good copy on flash in the router.
It comes down to your awesome Ninja router skills.
This is where a $100K network guy makes his money versus a $35K graduate.
EXPERIENCE.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548224</id>
	<title>Re:Document and test at night</title>
	<author>jdigriz</author>
	<datestamp>1261661520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Are we in the same business? No one ever notices IT when things go well.</htmltext>
<tokenext>Are we in the same business ?
No one ever notices IT when things go well .</tokentext>
<sentencetext>Are we in the same business?
No one ever notices IT when things go well.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547986</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548006</id>
	<title>Rancid?</title>
	<author>fuzzyfuzzyfungus</author>
	<datestamp>1261658880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It doesn't save you from <i>doing</i> stupid things; but putting your device configurations under revision control, using something like <a href="http://www.shrubbery.net/rancid/" title="shrubbery.net">Rancid</a> [shrubbery.net] can make rolling things back easier, as well as generally encouraging sanity around device configuration.</htmltext>
<tokenext>It does n't save you from doing stupid things ; but putting your device configurations under revision control , using something like Rancid [ shrubbery.net ] can make rolling things back easier , as well as generally encouraging sanity around device configuration .</tokentext>
<sentencetext>It doesn't save you from doing stupid things; but putting your device configurations under revision control, using something like Rancid [shrubbery.net] can make rolling things back easier, as well as generally encouraging sanity around device configuration.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548102</id>
	<title>Re:Pretty simple, really</title>
	<author>Anonymous</author>
	<datestamp>1261659840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>damn straight, thats why you get paid.</p><p>in theory, theory and practice are the same, in practice its not. you're job is to make it that way.</p><p>replace theory with lab and you see the fundamental flaw with the false sense of security a lab provides.</p></htmltext>
<tokenext>damn straight , thats why you get paid.in theory , theory and practice are the same , in practice its not .
you 're job is to make it that way.replace theory with lab and you see the fundamental flaw with the false sense of security a lab provides .</tokentext>
<sentencetext>damn straight, thats why you get paid.in theory, theory and practice are the same, in practice its not.
you're job is to make it that way.replace theory with lab and you see the fundamental flaw with the false sense of security a lab provides.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547930</id>
	<title>Re:  Testing Network Changes When No Test Labs Exi</title>
	<author>droz037</author>
	<datestamp>1261658100000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I would suggest asking your vendors for demo or evaluation equipment. Cisco, Juniper and 3Com have pools of demo equipment as do the resellers like PC Connection and CDW.</p><p>I've done deployments of new switching infrastructure based on work I've done with loaners from my vendors. It can be tough because the typical evaluation period is 30 days. Although you can get 45 and even 60 days.</p><p>If you have a good relationship with your sales rep. It would be easy to push them to get the necessary items to do basic testing and get the concepts down of how you need to deploy. Then get the config files so that when you do buy what you need you're 85\% of the way there.</p></htmltext>
<tokenext>I would suggest asking your vendors for demo or evaluation equipment .
Cisco , Juniper and 3Com have pools of demo equipment as do the resellers like PC Connection and CDW.I 've done deployments of new switching infrastructure based on work I 've done with loaners from my vendors .
It can be tough because the typical evaluation period is 30 days .
Although you can get 45 and even 60 days.If you have a good relationship with your sales rep. It would be easy to push them to get the necessary items to do basic testing and get the concepts down of how you need to deploy .
Then get the config files so that when you do buy what you need you 're 85 \ % of the way there .</tokentext>
<sentencetext>I would suggest asking your vendors for demo or evaluation equipment.
Cisco, Juniper and 3Com have pools of demo equipment as do the resellers like PC Connection and CDW.I've done deployments of new switching infrastructure based on work I've done with loaners from my vendors.
It can be tough because the typical evaluation period is 30 days.
Although you can get 45 and even 60 days.If you have a good relationship with your sales rep. It would be easy to push them to get the necessary items to do basic testing and get the concepts down of how you need to deploy.
Then get the config files so that when you do buy what you need you're 85\% of the way there.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547976</id>
	<title>Tools</title>
	<author>Anonymous</author>
	<datestamp>1261658580000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>5</modscore>
	<htmltext><p>Here are a few tools:</p><p>GNS3 - <a href="http://www.gns3.net/" title="gns3.net">http://www.gns3.net/</a> [gns3.net] - free network simulator, based on Dynamips Cisco emulator<br>Opnet - <a href="http://www.opnet.com/" title="opnet.com">http://www.opnet.com/</a> [opnet.com] - detailed planning of networks, from scratch<br>Traffic Explorer - <a href="http://packetdesign.com/" title="packetdesign.com">http://packetdesign.com/</a> [packetdesign.com] - plan changes to an existing network</p></htmltext>
<tokenext>Here are a few tools : GNS3 - http : //www.gns3.net/ [ gns3.net ] - free network simulator , based on Dynamips Cisco emulatorOpnet - http : //www.opnet.com/ [ opnet.com ] - detailed planning of networks , from scratchTraffic Explorer - http : //packetdesign.com/ [ packetdesign.com ] - plan changes to an existing network</tokentext>
<sentencetext>Here are a few tools:GNS3 - http://www.gns3.net/ [gns3.net] - free network simulator, based on Dynamips Cisco emulatorOpnet - http://www.opnet.com/ [opnet.com] - detailed planning of networks, from scratchTraffic Explorer - http://packetdesign.com/ [packetdesign.com] - plan changes to an existing network</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548688</id>
	<title>Re:Virtualization?</title>
	<author>Bios\_Hakr</author>
	<datestamp>1261669380000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>If you work a pure Cisco environment, talk to your Cisco guy about getting Packet Tracer.  Emulates a few routers and a lot of switches.  It works really well.  Plus, 5.1 adds virtual networking.  You can design several networks on several laptops and then join those networks over a virtual internet.</p></htmltext>
<tokenext>If you work a pure Cisco environment , talk to your Cisco guy about getting Packet Tracer .
Emulates a few routers and a lot of switches .
It works really well .
Plus , 5.1 adds virtual networking .
You can design several networks on several laptops and then join those networks over a virtual internet .</tokentext>
<sentencetext>If you work a pure Cisco environment, talk to your Cisco guy about getting Packet Tracer.
Emulates a few routers and a lot of switches.
It works really well.
Plus, 5.1 adds virtual networking.
You can design several networks on several laptops and then join those networks over a virtual internet.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547860</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548196</id>
	<title>Re:The tag says it all</title>
	<author>Anonymous</author>
	<datestamp>1261661220000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Rollback and commiting can be found in Cisco IOS XE, Cisco IOS NX-OS and Cisco IOS XR. So any high end platform that needs these functions...</p></htmltext>
<tokenext>Rollback and commiting can be found in Cisco IOS XE , Cisco IOS NX-OS and Cisco IOS XR .
So any high end platform that needs these functions.. .</tokentext>
<sentencetext>Rollback and commiting can be found in Cisco IOS XE, Cisco IOS NX-OS and Cisco IOS XR.
So any high end platform that needs these functions...</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548654</id>
	<title>You answered your own question.</title>
	<author>mnslinky</author>
	<datestamp>1261668720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>As you already said, we secretly test on production in such cases.</p></htmltext>
<tokenext>As you already said , we secretly test on production in such cases .</tokentext>
<sentencetext>As you already said, we secretly test on production in such cases.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551610</id>
	<title>A simple trick that might help in some instances</title>
	<author>jon3k</author>
	<datestamp>1261765920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Not a cure-all by any means, but one more trick for the toolbox.  Very useful during a maintenance window.  Obviously Cisco specific.
<br> <br>
(tftp/scp/etc new-config to router)
<br> <br>
router# reload in 2<br>
router# copy flash://new-config run
<br> <br>
(something along those lines, this is off the top of my head, basically copy your new config to the running config)
<br> <br>
if it works, wr it to startup config, if you get disconnected, wait 2 minutes for the router to reboot and automatically load the previous startup-config.  Adjust the time as necessary depending on change/complexity.
<br> <br>
Also use something like <a href="http://www.shrubbery.net/rancid/" title="shrubbery.net">RANCID</a> [shrubbery.net] or <a href="http://www.kiwisyslog.com/kiwi-cattools-overview/" title="kiwisyslog.com">KiwiCatTools</a> [kiwisyslog.com] to help handle managing your configuration changes.
<br> <br>
<b>But the best trick of all is using a full blown router emulator like <a href="http://www.gns3.net/" title="gns3.net">gns3</a> [gns3.net].</b>
<br> <br>
It's a MIPS emulator that loads unmodified IOS images.  You can build complex scenarios and even attach them to NICs on the host PC.  I've built labs with several routers attached to bridged NICs in VMWare guests.  So you can literally start, say, a webserver on one vmware guest and access it across your gns3 "network".  You can also bridge it to physical NICs -- you could have a 7206vxr router running on an old PC!
<br> <br>
Plenty of limitations.  Namely it can only run a specific set of IOS images for specific models and you have to use an NM-16ESW to simulate switching since switching is done in ASICs.</htmltext>
<tokenext>Not a cure-all by any means , but one more trick for the toolbox .
Very useful during a maintenance window .
Obviously Cisco specific .
( tftp/scp/etc new-config to router ) router # reload in 2 router # copy flash : //new-config run ( something along those lines , this is off the top of my head , basically copy your new config to the running config ) if it works , wr it to startup config , if you get disconnected , wait 2 minutes for the router to reboot and automatically load the previous startup-config .
Adjust the time as necessary depending on change/complexity .
Also use something like RANCID [ shrubbery.net ] or KiwiCatTools [ kiwisyslog.com ] to help handle managing your configuration changes .
But the best trick of all is using a full blown router emulator like gns3 [ gns3.net ] .
It 's a MIPS emulator that loads unmodified IOS images .
You can build complex scenarios and even attach them to NICs on the host PC .
I 've built labs with several routers attached to bridged NICs in VMWare guests .
So you can literally start , say , a webserver on one vmware guest and access it across your gns3 " network " .
You can also bridge it to physical NICs -- you could have a 7206vxr router running on an old PC !
Plenty of limitations .
Namely it can only run a specific set of IOS images for specific models and you have to use an NM-16ESW to simulate switching since switching is done in ASICs .</tokentext>
<sentencetext>Not a cure-all by any means, but one more trick for the toolbox.
Very useful during a maintenance window.
Obviously Cisco specific.
(tftp/scp/etc new-config to router)
 
router# reload in 2
router# copy flash://new-config run
 
(something along those lines, this is off the top of my head, basically copy your new config to the running config)
 
if it works, wr it to startup config, if you get disconnected, wait 2 minutes for the router to reboot and automatically load the previous startup-config.
Adjust the time as necessary depending on change/complexity.
Also use something like RANCID [shrubbery.net] or KiwiCatTools [kiwisyslog.com] to help handle managing your configuration changes.
But the best trick of all is using a full blown router emulator like gns3 [gns3.net].
It's a MIPS emulator that loads unmodified IOS images.
You can build complex scenarios and even attach them to NICs on the host PC.
I've built labs with several routers attached to bridged NICs in VMWare guests.
So you can literally start, say, a webserver on one vmware guest and access it across your gns3 "network".
You can also bridge it to physical NICs -- you could have a 7206vxr router running on an old PC!
Plenty of limitations.
Namely it can only run a specific set of IOS images for specific models and you have to use an NM-16ESW to simulate switching since switching is done in ASICs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30584338</id>
	<title>Re:Download vyatta</title>
	<author>Anonymous</author>
	<datestamp>1262114280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Replacing Cisco routers with cheap 1U servers is an awesome plan because networks of course only consist of ethernet interfaces.</p></htmltext>
<tokenext>Replacing Cisco routers with cheap 1U servers is an awesome plan because networks of course only consist of ethernet interfaces .</tokentext>
<sentencetext>Replacing Cisco routers with cheap 1U servers is an awesome plan because networks of course only consist of ethernet interfaces.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548064</id>
	<title>Go virtual!</title>
	<author>leegaard</author>
	<datestamp>1261659480000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>If you are unable to recycle old equipment into your testlab you should go virtual.</p><p>For Cisco routers, GSN3/Dynamips (www.gns3.net) is your friend. Any recent PC or laptop will allow you to build a large and complex topology that will satisfy most experiments and even support you when doing certification preparation. It will only work for routers so switch-based platforms are out (like the 3570,6500 and 7600). The good news is that the features are more or less the same and they more or less behave the same way. If "more or less" is not close enough you need a replica of your production network or at least a few devices of each to test what can be labelled as critical.</p><p>For Juniper routers, google juniper Olive. It will run a juniper router the same way dynamips runs a Cisco router.</p><p>In both cases a proactive partnership deal with the vendor will be a good idea. Both Cisco and Juniper (and I am sure all other major network vendors) have programs where they will more or less advise, test and prepare the configurations for you. If you run a critical network this is money well spent.</p><p>In the end it comes down to the level of risk your management is willing to take. Ask them if they will allow the network to be less up since you are unable to properly test your changes before implementation.</p></htmltext>
<tokenext>If you are unable to recycle old equipment into your testlab you should go virtual.For Cisco routers , GSN3/Dynamips ( www.gns3.net ) is your friend .
Any recent PC or laptop will allow you to build a large and complex topology that will satisfy most experiments and even support you when doing certification preparation .
It will only work for routers so switch-based platforms are out ( like the 3570,6500 and 7600 ) .
The good news is that the features are more or less the same and they more or less behave the same way .
If " more or less " is not close enough you need a replica of your production network or at least a few devices of each to test what can be labelled as critical.For Juniper routers , google juniper Olive .
It will run a juniper router the same way dynamips runs a Cisco router.In both cases a proactive partnership deal with the vendor will be a good idea .
Both Cisco and Juniper ( and I am sure all other major network vendors ) have programs where they will more or less advise , test and prepare the configurations for you .
If you run a critical network this is money well spent.In the end it comes down to the level of risk your management is willing to take .
Ask them if they will allow the network to be less up since you are unable to properly test your changes before implementation .</tokentext>
<sentencetext>If you are unable to recycle old equipment into your testlab you should go virtual.For Cisco routers, GSN3/Dynamips (www.gns3.net) is your friend.
Any recent PC or laptop will allow you to build a large and complex topology that will satisfy most experiments and even support you when doing certification preparation.
It will only work for routers so switch-based platforms are out (like the 3570,6500 and 7600).
The good news is that the features are more or less the same and they more or less behave the same way.
If "more or less" is not close enough you need a replica of your production network or at least a few devices of each to test what can be labelled as critical.For Juniper routers, google juniper Olive.
It will run a juniper router the same way dynamips runs a Cisco router.In both cases a proactive partnership deal with the vendor will be a good idea.
Both Cisco and Juniper (and I am sure all other major network vendors) have programs where they will more or less advise, test and prepare the configurations for you.
If you run a critical network this is money well spent.In the end it comes down to the level of risk your management is willing to take.
Ask them if they will allow the network to be less up since you are unable to properly test your changes before implementation.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551046</id>
	<title>Re:Download vyatta</title>
	<author>Anonymous</author>
	<datestamp>1261759320000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>this is what i do. Of course i use vyatta on my production routers too.</p></htmltext>
<tokenext>this is what i do .
Of course i use vyatta on my production routers too .</tokentext>
<sentencetext>this is what i do.
Of course i use vyatta on my production routers too.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30552426</id>
	<title>Dynamips</title>
	<author>klashn</author>
	<datestamp>1261733880000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>For Cisco equipment you can get the Dynamips emulator. You must provide the Cisco IOS - which must be licensed from Cisco for your use. You can then emulate pretty much the whole range of Cisco switches/routers on your PC. It's pretty good for a small test lab, but I'm not sure for a full production test lab</htmltext>
<tokenext>For Cisco equipment you can get the Dynamips emulator .
You must provide the Cisco IOS - which must be licensed from Cisco for your use .
You can then emulate pretty much the whole range of Cisco switches/routers on your PC .
It 's pretty good for a small test lab , but I 'm not sure for a full production test lab</tokentext>
<sentencetext>For Cisco equipment you can get the Dynamips emulator.
You must provide the Cisco IOS - which must be licensed from Cisco for your use.
You can then emulate pretty much the whole range of Cisco switches/routers on your PC.
It's pretty good for a small test lab, but I'm not sure for a full production test lab</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30552074</id>
	<title>Many think this is normal</title>
	<author>CyberLife</author>
	<datestamp>1261771920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It's highly distressing to encounter these people, but many, tech and manager alike, actually think there's nothing wrong with working on production systems. To them that's just how it's done. They know no other way. Trying to educate them is met with blank stares and sometimes even harsh resistance.</p></htmltext>
<tokenext>It 's highly distressing to encounter these people , but many , tech and manager alike , actually think there 's nothing wrong with working on production systems .
To them that 's just how it 's done .
They know no other way .
Trying to educate them is met with blank stares and sometimes even harsh resistance .</tokentext>
<sentencetext>It's highly distressing to encounter these people, but many, tech and manager alike, actually think there's nothing wrong with working on production systems.
To them that's just how it's done.
They know no other way.
Trying to educate them is met with blank stares and sometimes even harsh resistance.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830</id>
	<title>Pretty simple, really</title>
	<author>Anonymous</author>
	<datestamp>1261657020000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Whenever you're working in/on a production environment, only one rule matters:</p><p>Don't fuck it up.</p></htmltext>
<tokenext>Whenever you 're working in/on a production environment , only one rule matters : Do n't fuck it up .</tokentext>
<sentencetext>Whenever you're working in/on a production environment, only one rule matters:Don't fuck it up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548572</id>
	<title>Re:Pretty simple, really</title>
	<author>Anonymous</author>
	<datestamp>1261667400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>If you haven't fucked something up in production, I don't want you on the team fixing my network when something DOES accidentally go wrong in production.</htmltext>
<tokenext>If you have n't fucked something up in production , I do n't want you on the team fixing my network when something DOES accidentally go wrong in production .</tokentext>
<sentencetext>If you haven't fucked something up in production, I don't want you on the team fixing my network when something DOES accidentally go wrong in production.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548102</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551072</id>
	<title>Re:The tag says it all</title>
	<author>YojimboJango</author>
	<datestamp>1261759920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Not to point out flaws in your plan, but most banks have disaster recovery center.  Actually iirc it's a requirement for PCI compliance.</p><p>If you're responsible to have a separate HQ building ready to roll over to in the event of a disaster why are you not using that as a test bed.  Added bonus, your disaster recovery center will almost always be more up to date than your main.</p></htmltext>
<tokenext>Not to point out flaws in your plan , but most banks have disaster recovery center .
Actually iirc it 's a requirement for PCI compliance.If you 're responsible to have a separate HQ building ready to roll over to in the event of a disaster why are you not using that as a test bed .
Added bonus , your disaster recovery center will almost always be more up to date than your main .</tokentext>
<sentencetext>Not to point out flaws in your plan, but most banks have disaster recovery center.
Actually iirc it's a requirement for PCI compliance.If you're responsible to have a separate HQ building ready to roll over to in the event of a disaster why are you not using that as a test bed.
Added bonus, your disaster recovery center will almost always be more up to date than your main.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548554</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548076</id>
	<title>if you ask for it, you may not get it...</title>
	<author>Anonymous</author>
	<datestamp>1261659540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>but if you write a proposal and show the benefits of having the right equipment and the operational costs of not having the right equipment, you might be able to get a spirent testcenter. Do a demo with some linux/*bsd boxes running iperf, but remind them of the features and abilities you will get with quality network testing tools.</p></htmltext>
<tokenext>but if you write a proposal and show the benefits of having the right equipment and the operational costs of not having the right equipment , you might be able to get a spirent testcenter .
Do a demo with some linux/ * bsd boxes running iperf , but remind them of the features and abilities you will get with quality network testing tools .</tokentext>
<sentencetext>but if you write a proposal and show the benefits of having the right equipment and the operational costs of not having the right equipment, you might be able to get a spirent testcenter.
Do a demo with some linux/*bsd boxes running iperf, but remind them of the features and abilities you will get with quality network testing tools.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548938</id>
	<title>Don't do it</title>
	<author>tedgyz</author>
	<datestamp>1261673520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Management hates paying for double the equipment, but for any production environment, it should be the cost of doing business. It minimizes risk and provides hot spares faster than an HP (or whatever) tech shows up.  You should get some duplicate hardware for staging.</p><p>If you can't do that, then refer to the <a href="http://ask.slashdot.org/comments.pl?sid=1489564&amp;cid=30547830" title="slashdot.org">earlier post</a> [slashdot.org] - don't fsck up.</p></htmltext>
<tokenext>Management hates paying for double the equipment , but for any production environment , it should be the cost of doing business .
It minimizes risk and provides hot spares faster than an HP ( or whatever ) tech shows up .
You should get some duplicate hardware for staging.If you ca n't do that , then refer to the earlier post [ slashdot.org ] - do n't fsck up .</tokentext>
<sentencetext>Management hates paying for double the equipment, but for any production environment, it should be the cost of doing business.
It minimizes risk and provides hot spares faster than an HP (or whatever) tech shows up.
You should get some duplicate hardware for staging.If you can't do that, then refer to the earlier post [slashdot.org] - don't fsck up.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547948</id>
	<title>Let it burn</title>
	<author>Anonymous</author>
	<datestamp>1261658280000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>One problem with the situation you are in, is that you've got a work-around that has sufficed so far. So, you might WANT a test lab, but clearly you don't NEED one... because hey, if you needed it you couldn't have got all this production stuff working, right? The only way this changes is when you've got multiple teams dealing with a production outage that takes a long time and costs a lot of money because you have to do some trial-and-error fixes to isolate the problem. Only THEN will you get your test lab, after an appropriate amount of paperwork and delay. The trick is doing this without the outage being perceived as your fault.<br>
&nbsp;</p></htmltext>
<tokenext>One problem with the situation you are in , is that you 've got a work-around that has sufficed so far .
So , you might WANT a test lab , but clearly you do n't NEED one... because hey , if you needed it you could n't have got all this production stuff working , right ?
The only way this changes is when you 've got multiple teams dealing with a production outage that takes a long time and costs a lot of money because you have to do some trial-and-error fixes to isolate the problem .
Only THEN will you get your test lab , after an appropriate amount of paperwork and delay .
The trick is doing this without the outage being perceived as your fault .
 </tokentext>
<sentencetext>One problem with the situation you are in, is that you've got a work-around that has sufficed so far.
So, you might WANT a test lab, but clearly you don't NEED one... because hey, if you needed it you couldn't have got all this production stuff working, right?
The only way this changes is when you've got multiple teams dealing with a production outage that takes a long time and costs a lot of money because you have to do some trial-and-error fixes to isolate the problem.
Only THEN will you get your test lab, after an appropriate amount of paperwork and delay.
The trick is doing this without the outage being perceived as your fault.
 </sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549088</id>
	<title>Re:The tag says it all</title>
	<author>Anonymous</author>
	<datestamp>1261675560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Just make sure it works on your boss's system.</p><p>Mystery soved</p></htmltext>
<tokenext>Just make sure it works on your boss 's system.Mystery soved</tokentext>
<sentencetext>Just make sure it works on your boss's system.Mystery soved</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547960</id>
	<title>Packet Life</title>
	<author>z4ns4stu</author>
	<datestamp>1261658400000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext>Stretch, over at <a href="http://packetlife.net/blog" title="packetlife.net" rel="nofollow">Packet Life</a> [packetlife.net] has a great <a href="http://packetlife.net/lab/" title="packetlife.net" rel="nofollow">lab</a> [packetlife.net] set up that anyone who needs to test Cisco configurations on can sign up for and use.</htmltext>
<tokenext>Stretch , over at Packet Life [ packetlife.net ] has a great lab [ packetlife.net ] set up that anyone who needs to test Cisco configurations on can sign up for and use .</tokentext>
<sentencetext>Stretch, over at Packet Life [packetlife.net] has a great lab [packetlife.net] set up that anyone who needs to test Cisco configurations on can sign up for and use.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549744</id>
	<title>Re:Document and test at night</title>
	<author>mcrbids</author>
	<datestamp>1261731720000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><i>4) Once the inevitable failure occurs, haul out the paper trail and get the bean counter fired. Repeat until test lab is approved. Note, step 4 may get you fired instead. Business decisions are somewhat nondeterministic.</i></p><p>And this is the part that SUCKS.... A while back, I was part of a three-way integration project, with myself (representing a vendor), another vendor, and the ultimate customer. In advance, I'd talked through everything with the other vendor so we had a clear plan, including a verification step to cross-check the accuracy of the integration.</p><p>Confident, I went into the meeting, we presented our plan, the customer agreed, and all was going well, until when, in what I thought was going to be a closing step, I reiterated the entire plan from beginning to end.</p><p>The other vendor decided that this was a good time to disagree with the plan that had already been agreed to, and that doing the cross-check was not valuable. I came out strongly, indicating that the system could not be trusted unless the cross check was built. After going back and forth for a while, the customer decided they didn't want to pay for it.</p><p>So the plan went forward, and I was predicting that it wouldn't work, and why it wouldn't work. And when it didn't work, I was accused by the customer AND THE OTHER VENDOR of trying not to make it work! The situation went from bad to worse, to worse still.</p><p>Finally, I ended up building the cross-check, on my dime. I was PISSED. Even after the cross-check was built, and the problems started to show clearly rather than just be vague, I never got anything more than a nod.</p><p>You can believe that my further dealings with the client and the third party were markedly more reserved after that. Being the "hero" who has the answer in a flash, and saves the day is over-rated. Far better to hint that the problem is difficult to solve and take your time answering the question!</p></htmltext>
<tokenext>4 ) Once the inevitable failure occurs , haul out the paper trail and get the bean counter fired .
Repeat until test lab is approved .
Note , step 4 may get you fired instead .
Business decisions are somewhat nondeterministic.And this is the part that SUCKS.... A while back , I was part of a three-way integration project , with myself ( representing a vendor ) , another vendor , and the ultimate customer .
In advance , I 'd talked through everything with the other vendor so we had a clear plan , including a verification step to cross-check the accuracy of the integration.Confident , I went into the meeting , we presented our plan , the customer agreed , and all was going well , until when , in what I thought was going to be a closing step , I reiterated the entire plan from beginning to end.The other vendor decided that this was a good time to disagree with the plan that had already been agreed to , and that doing the cross-check was not valuable .
I came out strongly , indicating that the system could not be trusted unless the cross check was built .
After going back and forth for a while , the customer decided they did n't want to pay for it.So the plan went forward , and I was predicting that it would n't work , and why it would n't work .
And when it did n't work , I was accused by the customer AND THE OTHER VENDOR of trying not to make it work !
The situation went from bad to worse , to worse still.Finally , I ended up building the cross-check , on my dime .
I was PISSED .
Even after the cross-check was built , and the problems started to show clearly rather than just be vague , I never got anything more than a nod.You can believe that my further dealings with the client and the third party were markedly more reserved after that .
Being the " hero " who has the answer in a flash , and saves the day is over-rated .
Far better to hint that the problem is difficult to solve and take your time answering the question !</tokentext>
<sentencetext>4) Once the inevitable failure occurs, haul out the paper trail and get the bean counter fired.
Repeat until test lab is approved.
Note, step 4 may get you fired instead.
Business decisions are somewhat nondeterministic.And this is the part that SUCKS.... A while back, I was part of a three-way integration project, with myself (representing a vendor), another vendor, and the ultimate customer.
In advance, I'd talked through everything with the other vendor so we had a clear plan, including a verification step to cross-check the accuracy of the integration.Confident, I went into the meeting, we presented our plan, the customer agreed, and all was going well, until when, in what I thought was going to be a closing step, I reiterated the entire plan from beginning to end.The other vendor decided that this was a good time to disagree with the plan that had already been agreed to, and that doing the cross-check was not valuable.
I came out strongly, indicating that the system could not be trusted unless the cross check was built.
After going back and forth for a while, the customer decided they didn't want to pay for it.So the plan went forward, and I was predicting that it wouldn't work, and why it wouldn't work.
And when it didn't work, I was accused by the customer AND THE OTHER VENDOR of trying not to make it work!
The situation went from bad to worse, to worse still.Finally, I ended up building the cross-check, on my dime.
I was PISSED.
Even after the cross-check was built, and the problems started to show clearly rather than just be vague, I never got anything more than a nod.You can believe that my further dealings with the client and the third party were markedly more reserved after that.
Being the "hero" who has the answer in a flash, and saves the day is over-rated.
Far better to hint that the problem is difficult to solve and take your time answering the question!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549332</id>
	<title>Cisco Router</title>
	<author>blavallee</author>
	<datestamp>1261679040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>router# wr me<br>
router# reload in 30<br>
router# conf t<br>
router(config)# (good luck)<br><nobr> <wbr></nobr>.. disconnected from remote host (oops, wait for reload)</htmltext>
<tokenext>router # wr me router # reload in 30 router # conf t router ( config ) # ( good luck ) .. disconnected from remote host ( oops , wait for reload )</tokentext>
<sentencetext>router# wr me
router# reload in 30
router# conf t
router(config)# (good luck) .. disconnected from remote host (oops, wait for reload)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549720</id>
	<title>Don't just blame the management...</title>
	<author>MindPrison</author>
	<datestamp>1261774080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>...You're as guilty - if not MUCH more - than they are here....</p><p>Quoting you: "Management often expects us to get a job done but refuse to provide funds for expensive lab equipment"</p><p>Well, have you considered it might be that you may not have informed the management from the start what's to be expected in the future? If there is ONE THING that the management does well and knows better than most of us - is how to EARN and KEEP money, they trust YOU to do your job and know everything about it so it doesn't have to be a future headache for them. If you FAILED to INFORM them of your possible needs in the beginning, you  have yourself to blame buddy.</p><p>You're not alone though, I've been there myself...trying to convince my bosses why I need all that extra gear to keep it safe in the future - when everything has worked FINE so far.</p><p>So - be prepared - rather than complaining later.</p></htmltext>
<tokenext>...You 're as guilty - if not MUCH more - than they are here....Quoting you : " Management often expects us to get a job done but refuse to provide funds for expensive lab equipment " Well , have you considered it might be that you may not have informed the management from the start what 's to be expected in the future ?
If there is ONE THING that the management does well and knows better than most of us - is how to EARN and KEEP money , they trust YOU to do your job and know everything about it so it does n't have to be a future headache for them .
If you FAILED to INFORM them of your possible needs in the beginning , you have yourself to blame buddy.You 're not alone though , I 've been there myself...trying to convince my bosses why I need all that extra gear to keep it safe in the future - when everything has worked FINE so far.So - be prepared - rather than complaining later .</tokentext>
<sentencetext>...You're as guilty - if not MUCH more - than they are here....Quoting you: "Management often expects us to get a job done but refuse to provide funds for expensive lab equipment"Well, have you considered it might be that you may not have informed the management from the start what's to be expected in the future?
If there is ONE THING that the management does well and knows better than most of us - is how to EARN and KEEP money, they trust YOU to do your job and know everything about it so it doesn't have to be a future headache for them.
If you FAILED to INFORM them of your possible needs in the beginning, you  have yourself to blame buddy.You're not alone though, I've been there myself...trying to convince my bosses why I need all that extra gear to keep it safe in the future - when everything has worked FINE so far.So - be prepared - rather than complaining later.</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548510
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548414
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547976
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549654
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548904
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549652
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551072
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548554
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549846
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549088
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548472
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548902
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548240
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548196
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30554272
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548224
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547986
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551046
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548514
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548830
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549048
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548688
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547964
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547860
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30584338
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551008
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548904
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30565636
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548572
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548102
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548500
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30580858
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547858
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548370
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548000
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549744
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_09_12_24_223217_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548674
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547988
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547858
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30580858
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548104
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547976
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548414
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548006
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548348
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547884
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548500
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548514
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548472
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548000
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548510
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548370
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549048
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547986
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548224
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30554272
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547886
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547830
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549846
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548102
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548572
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548904
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549654
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551008
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548902
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547860
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547964
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548688
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548066
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549266
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547848
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548830
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549088
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548240
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30565636
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30547970
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551026
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548196
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548674
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548554
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551072
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation09_12_24_223217.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30548364
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30551046
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30584338
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment09_12_24_223217.30549652
</commentlist>
</conversation>
