Just curious what testing protocol people use with router code (IOS or JunOS for example) when considering deployment of a new version. Obviously the deployment would be made incrementally, but I wonder if you do anything more than running it in a lab router for a couple of weeks before the initial deployment.
Thanks
-Tom
Just curious what testing protocol people use with router code (IOS or
JunOS for example) when considering deployment of a new version. Obviously
the deployment would be made incrementally, but I wonder if you do anything
more than running it in a lab router for a couple of weeks before the
initial deployment.
I had the habit of running almost every new IOS version through a series
of tests stressing both performance, convergence and the usualy switching
path bug stuff over a large compliment of interfaces. This was quite frustrating
experience since the vendor never really fixed most of the issues present,
some cases running for two to three years with reproducable problems.
(most rendering the box unusable)
I never got paid to do the same stuff for JunOS so I cannot comment on what
would happen if similar stream of bugs would be submitted to their direction.
Pete
Typically testing for (allegedly) fixed defects and historicial
problems unique to ones environment is normal.
Depending on the level of detail of buglists, etc.. people also
test to insure that there are no reintroduction of old bugs as well
as counter bugs, snmp issues, etc..
- jared
One of my favourites was inserting and removing configuration commands and watching
the alignment errors to run by or just a plain crash.
Or if you make the mistake of playing with EIGRP, you'll see the boxen spit out scheduler
related stuff.
Pete
Jared Mauch wrote: