I a previous job we lacked the identical (juniper) hardware mix in the lab that we had in the field (mx480s and srx 5600s are expensive). So for some upgrades things ran fine or were easy to identify, but there were failure cases whereas we tripped over hardware/software interactions in the field that we were not previously or subsequently able to replicate.
in terms of being bleeding edge, when the hardware platform being adobted is new there's often no alternative... Also it's been about a decade and a half since people paid the price for having 6 month validation cycles on cisco code, so you are at some point going to run something that you haven't had as much confidence with as you'd like. On 4/13/11 10:27 AM, Chris Evans wrote: > Question to you all... > > It seems like alot of folks run bleeding edge code with some if these major > bugs popping up.I also get the impression that a lot of shops don't test > code before they deploy. > > I'm just curious how this works for you. In my company we would get > seriously reprimanded for deploying software that is not tested and any time > we have outages we have to go through big hoops to understand why how to fix > etc.. so we do the best we can to deploy architectures/platforms/code that > wont have issues. > > I couldn't imagine being bleeding edge in a service provider environment, > its just a concept I can't fathom being in the environment I'm in.. > > Looking for input... > > Thanks > On Apr 13, 2011 1:15 PM, "Keith" <kwo...@citywest.ca> wrote: > _______________________________________________ > juniper-nsp mailing list juniper-nsp@puck.nether.net > https://puck.nether.net/mailman/listinfo/juniper-nsp > _______________________________________________ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
